Slow switching of Views - Long thread

[chaley]

Originally Posted by jnikkir

Edit: Now that I think about it, does this account for the lag even when Action Chains wasn't doing anything, though? Just manually changing views without clicking on VL tabs has a lag too...

Clicking on a VL tab triggers action chains.

Try selecting the view/VL using the View Manager menu. I don't see the delay there.

[nikosan]

Originally Posted by chaley

Clicking on a VL tab triggers action chains.

Try selecting the view/VL using the View Manager menu. I don't see the delay there.

Right... Even when I've uninstalled Action Chains, or disabled it, I still have the delay when manually selecting the view in the VM menu...

[chaley]

Originally Posted by jnikkir

Right... Even when I've uninstalled Action Chains, or disabled it, I still have the delay when manually selecting the view in the VM menu...

I don't see that.

• How did you disable action chains? The plugin manager won't allow it.
• When I deleted the action chains plugin the delays went away. When I reinstalled it the delay came back.

[chaley]

Originally Posted by jnikkir

Right... Even when I've uninstalled Action Chains, or disabled it, I still have the delay when manually selecting the view in the VM menu...

Also, I didn't suggest choosing the VL in the VL menu. I suggested choosing the View in the View Manager plugin.

[nikosan]

Originally Posted by chaley

I don't see that.

• How did you disable action chains? The plugin manager won't allow it.
• When I deleted the action chains plugin the delays went away. When I reinstalled it the delay came back.

I deleted all the rules from the Action Chains settings.

Ran another test just now -- uninstalled Action Chains, still getting the exact same lag when CTRL+Tabbing between my views. And the same rattly sound BR mentioned they get too (below)

Originally Posted by BetterRed

But here's the rub, VM switching on jnikkir's library was also rattly - I could hear disk r/w heads moving - that's not happening on my bigger, and arguably more complex libraries.

On a whim, I put a copy of the library onto my 256GB SSD - result, VM switching near instantaneous. I admit that I've never been an SSD fan, not because there's anything wrong with them. But I'm not a speed freak and the claims for SSDs have IMO been over-hyped --- but this is the most dramatic effect I've seen from an SSD.

So, I tried moving the metadata.db file from the library folder on the rattly drive to the SSD and dropping a symlink to it in the library folder on the rattly drive. Guess what, less laggy and no rattling. Which seems to indicate that the disk I/O I can hear on the rattly drive is related to the metadata.db file - which surprises me.

I can't figure out why this tiddly little library should be rattling the disk drives cage but there's no doubt it is.

Originally Posted by chaley

Also, I didn't suggest choosing the VL in the VL menu. I suggested choosing the View in the View Manager plugin.

I think you misread my post -- that's what I'm doing. Picking the View Manager view from View Manager's dropdown menu.

[chaley]

Originally Posted by jnikkir

Ran another test just now -- uninstalled Action Chains, still getting the exact same lag when CTRL+Tabbing between my views. And the same rattly sound BR mentioned they get too (below)

I don't see any lag doing that, even with action chains installed.

The delay is very obvious when I click on a tab. That delay is gone if I click on the View Manager menu or use CTRL+Tab.

At this point I give up. There are too many uncontrolled variables.

[BetterRed]

Originally Posted by jnikkir

Edit: Now that I think about it, does this account for the lag even when Action Chains wasn't doing anything, though? Just manually changing views without clicking on VL tabs has a lag too...

I don't have, and never have had, the Action Chains plugin installed.

The delays I've seen have on been on VM switching, no delays on Virtual Library switching. And hooking VLs into VM views makes no difference.

Curious : Where does Action Chains put its 'stuff', I couldn't see any additional tables in the database or in the metadata_db_prefs_backup.json file.

BR

[ownedbycats]

Originally Posted by BetterRed

Curious : Where does Action Chains put its 'stuff', I couldn't see any additional tables in the database or in the metadata_db_prefs_backup.json file.

BR

CALIBRE_CONFIG_DIRECTORY\plugins\Action Chains.json
and also a CALIBRE_CONFIG_DIRECTORY\plugins\action_chains\ subfolder

[chaley]

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.

[ownedbycats]

Since I switch views/VLs a lot and have noticed a slight delay on it, I'll be testing it once the PR gets approved.

[chaley]

Note: my changes don't affect the .25 sec - .75 sec delay that action chains inserts when processing a "VL changed" event before calling the view manager. The delay is quite visible.

The comments in the action chains code say that the delay is there to improve performance. I leave it to others to decide whether the lag is worth the performance improvement. It might not be once the extra save_state() calls are removed.

[chaley]

Originally Posted by ownedbycats

Since I switch views/VLs a lot and have noticed a slight delay on it, I'll be testing it once the PR gets approved.

The changes are now in source. Without changes to the VM plugin there will be two calls to save_state().

[ownedbycats]

Installed. There's a huge performance improvement. Changing VL tabs with the action chain to switch views is now nearly instant while before there was a slight but noticable delay.

[JimmXinu]

I'm willing to make such a change to View Manager, but it's a bit of a nuisance--right now at least.

calibre/master branch won't run from source for me using 5.38 binaries, gives:

  File "C:\Users\me\Desktop\nook\calibre\src\calibre\gui2\dialogs\choose_format_device_ui.py", line 9, in <module>
    from PyQt6 import QtCore, QtGui, QtWidgets
ModuleNotFoundError: No module named 'PyQt6'

Presumably something qt6 got into master.

And the calibre/qt6 branch doesn't have save_state yet.

So VM can't use calibre version >5.38 to decide when to call with save_state=False, has to do try: call() except TypeError:

[chaley]

Originally Posted by JimmXinu

calibre/master branch won't run from source for me using 5.38 binaries, gives:

  File "C:\Users\me\Desktop\nook\calibre\src\calibre\gui2\dialogs\choose_format_device_ui.py", line 9, in <module>
    from PyQt6 import QtCore, QtGui, QtWidgets
ModuleNotFoundError: No module named 'PyQt6'

Presumably something qt6 got into master.

Whenever you switch from V5 to the beta or back you must force recompilation of all the .ui files in calibre. Normally changes are automatically detected so that the *_ui.py files are regenerated, but the dates are 'wrong' when switching between branches so the files aren't rebuilt. The problem is discussed in posts starting with this one.

I know of two ways to force rebuilding the files:

• Delete all *_ui.py files in calibre.gui2, then run calibre-debug -g.
• Set the environment variable
  

  set CALIBRE_FORCE_BUILD_UI_FORMS=1

  before you run calibre-debug -g. This is what I do by setting the env var in the script I use to start calibre in debug mode. It tells calibre to ignore the timestamps and rebuild the _ui.py files.