QAP Support Forum

Full Version: Optimize saving changes
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hello Jean,
when saving a new entry with "Save & Close" it takes a long time until QAP is available again
In the toolbar the program runs through all elements.


1. Are all entries (approximately 300) of the QAP written or only the new/changed ones?
2. Does the display of each entry in the tooltip (create menu) possibly influence the speed?
Hi,

1. Are all entries (approximately 300) of the QAP written or only the new/changed ones?

All entries. When QAP is running, all items are kept in memory. Since many changes can be done before saving (some of them having impacts on other favorites, for example moving a submenu), all the items in memory have to be saved.

2. Does the display of each entry in the tooltip (create menu) possibly influence the speed?

No. The display of the tooltip is negligible. If it was removed you would not know what happens.
Ok, can I change something to make saving faster?
Unfortunately, I don't have a good answer to this. If you think of using a RAM disk or something like this, this will not make a significant difference. Most of the time is used to process the various properties/options to build an ini line for each favorite. QAP has many options and this comes at a certain processing cost. Also, the language used to build QAP (AHK) is interpreted which make its execution not as fast as compiled/optimized languages. The ball is on my side to see how the code could be optimized. But I doubt I could make it that much faster (I mean this would never be cut by half). Another option would be to produce a report of your least used favorites to help users help lighten the content of your ini file.
I also have a large amount of favorites, and see the same behavior.
It's not much difference in save speed between my machines with fairly new AMD Ryzen CPUs and NVMe SSDs, and machines with older CPUs and slower SATA SSDs.
In my opinion that in itself supports the explanation from Jean.

To my knowledge it is not much to do about it.
It would probably require a major redesign in the way QAP stores the data.
F.ex. something like a lightweight in-memory No-SQL DB to offload the save operation to another process (a mini Redis if such a thing exists).
The complexity of such a solution for a small and handy little tool like QAP is most likely not worth the hassle.

Another solution is to support multiple ini files to split the data into smaller chunks, and only process the file where the change happen (smaller files = faster saves).
I have 8 ini files (Shared Menus) but QAP handles those as "one" file during save.
Would probably also require a major redesign?

Regards,
joeNOR
SQLite is not involved in favorites saving. It is used to collect and process the recent/frequent items used to build dynamic menus. The favorites are saved to a ini file.

Saving the favorites to disk is a very tiny proportion of the time it takes to save your favorites. Most of the time is used to process the various properties/options for each favorite, converting them from their representation in memory to the ini line format. Then, QAP saves these line to the ini file, reloads the menu from the in file and rebuilds the menu. This is what takes time.
(2020-12-07 09:17)Jean Lalonde Wrote: [ -> ]SQLite is not involved in favorites saving. It is used to collect and process the recent/frequent items used to build dynamic menus. The favorites are saved to a ini file.

Saving the favorites to disk is a very tiny proportion of the time it takes to save your favorites. Most of the time is used to process the various properties/options for each favorite, converting them from their representation in memory to the ini line format. Then, QAP saves these line to the ini file, reloads the menu from the in file and rebuilds the menu. This is what takes time.

Maybe it makes sense not to save the data as ini file
Writing a CSV file might be faster?
Not that much. I made some calculation using a QAP ini file with 325 favorites. It took on my system:

1) 4.1 secs for saving the favorites
2) 3 secs for reloading the favorites
3) 3.5 secs for rebuilding the menu.

Total time 10.6 secs. From the 4.1 secs for saving, approx 0.9 sec was used for the actual saving to the ini file (the rest is for internal processing). Replacing the ini file with a simple text file (not a CSV) cut this time to 0.3 sec, a reduction of 0.6 sec. Assuming we would do the same gain at step 2 when reloading the favorites, replacing the file format alone would reduce by 1.2 secs, taking the total time from 10.6 to 9.4 secs. Not a game changer...

Now, maybe using the CSV format or SQLite to save favorites would produce additional gains by making the internal processing a little more efficient (at steps 1 and 2). But because this is a major change, I'm not sure the gains are worth the effort.

Another track to investigate is to see if I can avoid the reloading of the favorites (step 2). When saving, favorites are already in memory. Reloading was an early design decision (at the time of Folders Popup) to make sure we have fresh data in memory after saving. I added this to my todo list.
(2020-12-07 12:35)Jean Lalonde Wrote: [ -> ]When saving, favorites are already in memory. Reloading was an early design decision (at the time of Folders Popup) to make sure we have fresh data in memory after saving. I added this to my todo list.

This would be my suggestion. If they are already in memory, then its just about updating the memory that contains the info (which is fast) and you would save a few seconds with the reload time.

So, fairly easy change and the results are worth it.
I just realized doing some verifications for another thread that updating the tooltip (small popup text) about the progress of the save/reload/rebuild menu operations takes some time for little benefits. To follow-up on this change, I'll move this thread to the Wishlist section and rename it "Optimize saving changes".
More precisely, I change my answer to your question #2:

> 2. Does the display of each entry in the tooltip (create menu) possibly influence the speed?

I'd say yes if you have a large number of submenu. In the next release, instead of updating the tooltip at each submenu, I'll update it only 3 times, one for each step: save / reload / rebuild menu.