We have what I think is a huge dataset, 40+ sessions, 33 windows, and 36 tubes. With everything viewed in one Rootfly file, pc (running Vista) performance is very sluggish. I’m assuming that this is because of the size of the dataset… and the obvious remedy is to break the dataset into smaller units. Am I correct in this assumption, or is my average-sized dataset not being handled very well by Vista?
Chris A. suggests in his report (12/9/08) that CFileFind in ImageFileFormat::GetFileName is probably what is causing the sluggish performance. It seems to me that we could remove this function pretty safely.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jim wrote a new class (see ImageManager.h/cpp) to fix the sluggish bug, but he ran out of time before integrating it. We need to integrate this into the project. This should also help to clean up the codebase.
From Jim's email (4/30/09):
I have filled out the ImageManager interface and defined the class. I have tried many different ways to integrate this but keep getting railroaded. Creating an ImageManager object within the RootflyDlg class means that it doesn't have access to the places where images are gotten from files such as in UpdateSessions, UpdateWindows, and ReloadImageBuffers which are in the ApplicationData class. If I include the object in the ApplicationData class, then it can't be initialized during OnFileNew in RootflyDlg. If I include it in RootflyData, then I can't build the maps because the instances of RootflyData are const. Doing timing tests ensures it will speed up the software, though. Rather than having to open and load the files using blepo::Load, using ImageManager::GetImage is faster.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From John P. (10/28/08):
We have what I think is a huge dataset, 40+ sessions, 33 windows, and 36 tubes. With everything viewed in one Rootfly file, pc (running Vista) performance is very sluggish. I’m assuming that this is because of the size of the dataset… and the obvious remedy is to break the dataset into smaller units. Am I correct in this assumption, or is my average-sized dataset not being handled very well by Vista?
Chris A. suggests in his report (12/9/08) that CFileFind in ImageFileFormat::GetFileName is probably what is causing the sluggish performance. It seems to me that we could remove this function pretty safely.
Jim wrote a new class (see ImageManager.h/cpp) to fix the sluggish bug, but he ran out of time before integrating it. We need to integrate this into the project. This should also help to clean up the codebase.
From Jim's email (4/30/09):
I have filled out the ImageManager interface and defined the class. I have tried many different ways to integrate this but keep getting railroaded. Creating an ImageManager object within the RootflyDlg class means that it doesn't have access to the places where images are gotten from files such as in UpdateSessions, UpdateWindows, and ReloadImageBuffers which are in the ApplicationData class. If I include the object in the ApplicationData class, then it can't be initialized during OnFileNew in RootflyDlg. If I include it in RootflyData, then I can't build the maps because the instances of RootflyData are const. Doing timing tests ensures it will speed up the software, though. Rather than having to open and load the files using blepo::Load, using ImageManager::GetImage is faster.
Second bug assigned to abbott