Slow menus in large projects

It’s worth noting you can also go into Options: Keyboard, and adding a direct hotkey to the conversion command itself, so that you can access it without having to open the Documents menu, avoiding that long delay when accidentally opening up these binder menus.

Another aspect of my testing suggests the question: Could it be my extensive use of cross-links, including self-referential, that I use in the 25k file project? (The cross-links are ubiquitous, probably only in a few 100s of files?)

That should not cause an issue, nor would overall word count in most cases. Links are not indexed anywhere, and the back-links that do get created are unlike software that build these dynamically. We create back-links as static “Bookmarks” upon creation of the link. So this all stays very fast and capable of being edited for relevance.

I think the speed issue in these menus is largely down to it fully rebuilding the list every single time, and in theory that is something that can be improved. Having 25k binder items means building 25k menu commands per sub-menu. You can probably imagine from this where optimisation can be done. We can build that list once for all menus that work this way, probably as part of project loading, and modify that list dynamically as the binder changes during the session, rather than fully rebuilding it each and every time.

Thanks AmberV Ioa,
Yes, I had built a few hotkeys for other stuff and this time around, Win+Shift+F4.
(I’d found earlier btw that Ctrl+Alt+letter doesn’t work in editor windows; the result whatever intended comes out simply as the letter capitalized.)

Thank you too for the comments about re/building the lists during startup; what you say here is as you noted June 2021.
(A note for others about projects: I have one project with only ~ 740 files and far fewer Scrivener folders but with 605 MB of size; it takes 10-20 seconds to load, and the menus work fine. The 25k file project is 432 MB and takes 135-185 seconds to load.)

Could this be a table overflow issue during startup/loading?

Thank you again for your patience :innocent:

PS: Bad proofreading! Extensive crosslinks are NOT ubiquitous :upside_down_face: but they do tend to be many in their ‘few’ files/documents.

Could this be a table overflow issue during startup/loading?

If I understand you correctly, if you are referring to a memory issue, that would probably cause more severe problems than slowness in the menus, like crashes or hangs. As far as I’m aware Scrivener’s limits are more soft boundaries relating to performance, and our patience to put up with it. There probably is an actual limit to the number of binder items, given how programming works, but I bet it’s an obscenely high number nobody would ever encounter before slowing the system down to a crawl.

Thanks; I was thinking more like a soft processing error handling than a memory issue; after all, the list does get built successfully each time I call for it. (Maybe fully rebuilt rather than updated?)

As you say, scrambled or lost memory addresses sure would cause more macro issues.

It sure is curious: On that Documents menu e.g., resting on Copy To, it takes its usual slow ~ 23 seconds building its submenus, which work fine then – once each time. If I then move directly to the Move To above it, it takes another 23 seconds on its own.

One last point on which we exchanged back in June 2021 (here only to round this out): This project, ‘Works’, was fine and snappy in Scrivener v1; we wondered which it was, the project’s conversion to v3 or something about the project that v3 handles entirely differently now – I’m sure there is A LOT different going on in v3 even for the same UI result.

But then, my experience is nearly two decades past due now, mainframe and web besides.

thx, D.

Maybe fully rebuilt rather than updated?)

Yes, this is precisely what I was saying above. Each invocation of a binder item-based submenu does a full rebuild, every single time. To what level, and whether within the realm of what we can fix, I can’t say.