View Single Post
Old 03-08-2022, 06:56 AM   #54
chaley
Grand Sorcerer
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 12,488
Karma: 8065348
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
I couldn't help it -- given that action chains appears not to be involved I had to look further into this and I (think I) found the problem.

The VM calls gui.apply_state() (action.py line 341). One of the things that apply_state() does is reposition the columns as requested by the new state. Whenever a column is repositioned the method calls save_state(). Unfortunately for performance, jnikkir's views reposition columns a lot, resulting in a lot of save_state() calls.

I made a test version of apply_state() that calls save_state() once no matter how many columns are repositioned. That cut down the number of save_state() calls to 2, one in apply_state() and one in the VM (a direct call to save_state() on line 343).

As the VM is going to save the state anyway, even that first save_state() isn't needed. I am thinking about adding a parameter to apply_state() telling it whether or not to call save_state() even that one time. The VM can use this parameter to get rid of the extra save. It will need to condition using the parameter on calibre's version to maintain compatibility.

I will submit changes to Kovid once I am convinced I haven't broken anything.
chaley is offline   Reply With Quote