Project

General

Profile

Actions

Bug #8991

closed

New untitled csv files are slow to load.

Added by Kosta A. about 3 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
04/16/2021
Due date:
% Done:

100%

Estimated time:
Chirp Version:
daily
Model affected:
(All models)
Platform:
All
Debug Log:
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%.

Actions #1

Updated by Kosta A. about 3 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 100

Patch submitted to mailing list.

Actions #2

Updated by Kosta A. almost 3 years ago

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.

Actions #3

Updated by Kosta A. almost 3 years ago

  • Status changed from In Progress to Closed

Applied in changeset commit:013c090a8b1f.

Actions

Also available in: Atom PDF