To diagnose a really slow project load


My Scriv “project” is up to 9300 docs. Of course it’s just the kitchen sink. I accept a fairly slow project load as an inevitable consequence of the XML binder format and individual RTFs for doc storage. Though the load time can be a nuisance, these design choices enhance the value I derive from Scrivener in other ways, especially in its ease of scripting.

However, there’s a twist in 1.9.6 as against 1.9.0. In 1.9.0 a slow load took about six minutes. In 1.9.6 a slow load can take more than 18 minutes. :frowning:

Fortunately, it’s possible to assure a reasonably quick load of about 2.5 minutes. I simply make a full backup of the project automatically upon the prior shutdown. Whether the load is destined to be fast or slow, I can monitor its progress in Task Manager. When memory use reaches about 630 mb, the project is about to display.

Others since 1.9.5 have had difficulty loading their projects at all. Could there be a connection between their failed loads and my lately glacialized ones?

A few suggestions for the Windows devs, to help us ascertain.

First off, could we have a verbose project load? Whether the output is to screen or to file, we slow loaders would appreciate some report on what Scrivener is doing and which file it’s reading as the load clock ticks.

Second, I’d like a switch that enables the user to load the project against the XML binder alone. I surmise that there’s some reindexing or checking against checksums going on in a slow load. But it’d be nice to be able to load the binder as an interface to the docs as they are, even if it means locking out the search pending a reindex. I’ve tested: my binder loads in less than a minute when there are no Docs in the folder. I’d like to be able to load a project in that same trusting mode, and still be able to edit docs as Scriv finds them.

Finally, could the index be created or maintained in a separate EXE? True multi-threading may be out of reach, but a separate indexer executable, running in background, would enable the user to continue editing in Scrivener as it scanned the docs, even if Text Search were disabled in the process.

Thanks for considering!

Rgds — Jerome