Bug #8991
closed
New untitled csv files are slow to load.
Added by Kosta A. over 3 years ago.
Updated over 3 years ago.
Model affected:
(All models)
I read the instructions above:
Description
When creating an untitled csv file, the editor is quite slow to load - especially when "Show Empty" is enabled.
This is a result of the prefill being performed twice on every editor window in order to facilitate the setting of the 'default' memory. Most users will notice the window flash twice, as the treeview is initially populated with 1k memories, completely cleared, and then repopulated again with 1k memories.
Avoiding the unnecessary priming we can increase the speed of the creation of empty csv files by over 100%.
- Status changed from New to In Progress
- % Done changed from 0 to 100
Patch submitted to mailing list.
The change improved the speed by at least 100% by eliminating the redundant call to prefill (ie: get and set all 1000) generic csv memories...
The actual amount of time saved is a function of variety of factors due to the use of the gobject idle event manager, which executes function when there are no other high priority events pending on the UI thread. Specifically, when "Show Empty" is enabled, the GTK Window is busy adding/updating items into the tree view - thus allowing less opportunity for the event manager to process new idle tasks. This scenario is further compounded when attempting to open multiple new generic csv files concurrently. Basically the UI is throttling the loop of adding memories.
For example on my core i7 opening a single empty csv file takes on avg. about 1.3 - so 2.6s total to open before the optimization. However, the real saving begins to be realized when opening concurrent files as it can take up to 6s to open a single file when stressing the event queue.
The optimization here is to simply reduce the overall number of events by preventing redundant calls for both fetching memories and updating them in the UI. Ultimately, a more optimal process could be presented but it would require further decoupling from the UI thread which is out of scope for this change.
- Status changed from In Progress to Closed
Applied in changeset commit:013c090a8b1f.
Also available in: Atom
PDF