Bug #8991

New untitled csv files are slow to load.

Added by Kosta A. 6 months ago. Updated 4 months ago.

Status:Closed Start date:04/16/2021
Priority:Normal Due date:
Assignee:Kosta A. % Done:

100%

Category:-
Target version:chirp-daily
Chirp Version:daily Platform:All
Model affected:(All models)

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%.

Associated revisions

Revision 3521:585ca5b1e720
Added by Kosta A. 4 months ago

[csv] Memory bounds are inclusive. #8991

Revision 3522:a47f77ccadaa
Added by Kosta A. 4 months ago

Removing default support for Icom Dstar from generic csv radios. #8991

Revision 3524:013c090a8b1f
Added by Kosta A. 4 months ago

Optimizing generic csv files load times by removing duplicate load for an empty list. Fixes #8991

History

Updated by Kosta A. 6 months ago

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

Patch submitted to mailing list.

Updated by Kosta A. 4 months 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.

Updated by Kosta A. 4 months ago

  • Status changed from In Progress to Closed

Applied in changeset 013c090a8b1f.

Also available in: Atom PDF