What is making my .scriv file take longer to load and backup?

In the last few months, I have set myself the goal of ‘at least 1000 words per day’. I have met it well so far, but, as a consequence, it has fattened my Scrivener project.

It’s normal that a big project takes a long time to start, isn’t it? Sometimes it even takes minutes, even now, that I have a new and more powerful computer (with the previous pc, Scrivener took ages to start).

The thing is that, besides the 600K+ words that my manuscript now has (not counting what’s in the research folder), I also use quite a lot of comments and footnotes, as well as screenshots (which I’ve seen that they have their own folder next to the .scriv file and that takes up more size than everything else in my Scrivener project) and that has made me think… which of these things is it that is slowing down the loading and backup of Scrivener? Is it all at once or is there a specific feature that is slowing it all down?

I’d like to know so I can see if I can do something to ease the loading and backup process. Does anyone know anything about this?

Hugs and thanks,
Ainoa

What you could try is go into Options, and under General: Warnings, enable the logging option, then restart the software and load your project. You should see a list of everything it is loading when doing so, and if you’re seeing a lot of stuff loading that might explain why it is going slow.

There are some things you can do to make a project start up slower, like leaving Scrivenings open to a huge amount of text. You could try a test of making sure only one thing is showing in the editor and reloading, and seeing if that makes a substantial difference in how much is loading in the log window, and secondly if it loads quicker.

The size of your project will have a direct impact on time necessary to back up and shut down Scrivener, so whatever is making your project larger will also make your backups take longer. See this post that explains what Scrivener does during the backup process.

Even 600k+ of words would likely not not cause very long backup times, so the cause is likely all your images.

As an alternative to storing your images directly in the Scrivener project, you could keep them in a folder external to your project and point to them from within Scrivener using Insert > Image Linked to File.

The advantage of this approach is that your project will be smaller in size, your backups shorter in duration, and your zipped backup files themselves will also be smaller in size.

The disadvantage is that you will need a separate process to backup your images. (You should already have a separate process to back up your entire PC, so in that case that would also backup your images.)

Best,
Jim

1 Like

I have tried doing this and yes, it does indeed load quite a few files on startup. From the list it shows me, the vast majority are not files that I am currently using or displaying, is that normal?

It does speed up the startup by not displaying a lot of files in the editor, so thank you a lot for that :heart:, although the backup still takes a while.

Oh, I was referring to the screenshots as a function, the one that tracks the different versions of the documents. I don’t use images in my project, I think in total I only have 3 PDFs and one image, the rest is just text, so it can’t be that :thinking:
(Although, if I ever use images, I’m definitely going to apply your advice :heart:).

My plan is to quadruple the amount of words I have, so I have to do something about this…

Also, the post you mention confuses me. For me, the zip backup takes much less time than the ‘normal’ (non-zip) backup (which is the one that’s taking a very long time). The problem is that I don’t want my backups in zip, because then it takes a long time to unzip, so… Is there something I’m not understanding correctly?

1 Like

Something to consider is that we do provide a checkbox for switching automatic backups off for individual projects (in the Project ▸ Project Settings... window, under “Backups”). While there are a number of reasons you might use that, for this reason: large projects can be slow to back up and so sometimes it better to manage your own backups—typically with something that works automatically and in the background, such as nightly, so it doesn’t get in the way of working. Just don’t skip setting up that part of the equation, if you do choose to switch them off for this project (and really, you should have something like that anyway, at the least, on top of any Scrivener backups).

Also try turning off the zip compression option in the main Backup options tab. That adds a lot overhead. One downside is that your backup folder will be a lot bigger, but drive space is cheap—the bigger downside is that it is possible to accidentally live load a backup. Just be careful with them if you use that, and always create full copies in File Explorer, to another location, when looking through backup copies.

Also, the post you mention confuses me. For me, the zip backup takes much less time than the ‘normal’ (non-zip) backup (which is the one that’s taking a very long time).

So to clarify, there is some confusion there. Duplicating files across to a different folder is way faster than duplicating the files and then zip archiving them.

I have tried doing this and yes, it does indeed load quite a few files on startup. From the list it shows me, the vast majority are not files that I am currently using or displaying, is that normal?

I have noticed that some conditions can cause it to load too much on launch, but I’ve never managed to pin down what causes that. When doing very focused tests I always get what should be the correct result: only loading what is in an editor somewhere. For example if I have “Text A” in the main editor, and the inspector open to the Bookmarks tab, which is showing “Text B” in the lower half of the inspector, then on reload I see the RTF files for both of these files being loaded. Makes sense—it needs to show them. If I add “Text C” to the Bookmark list and leave it unselected, I still get the same result.

That’s just one example, there are so many things that might cause excessive and unwarranted loading though, that testing everything and all of the various combinations in between can be pretty time-consuming. If you spot anything in your project window layout that might be a clue, let me know.

Oh, I was referring to the screenshots as a function, the one that tracks the different versions of the documents.

Ah, Snapshots you mean. Those shouldn’t be of impact. Even if you happen to leave one selected in the inspector when you close the project, it doesn’t remember that on reload and won’t even load it. That would be just one single snapshot though.

Excessive snapshots will slow down backups though, as they are all individual files. Considering taking a full named backup (File ▸ Back Up ▸ Back Up To...) that indicates it has all your historic snapshots, and then go into Documents ▸ Snapshots ▸ Snapshots Manager and run a date search. For example, <1y is everything older than a year. Then you can select them all and click the - button at the bottom to bulk delete them. This is why you want to take a full backup that is set aside from the normal backup rotation, first. :slight_smile:

1 Like

Yes, that’s what I have been doing since my project grew. I make backups from time to time (when I have time to make them, since it takes a while) and I keep them on a separate hard drive (in non-zip) and in some places in the cloud (these ones in zip).

I’ll try.

Oops. Yes, that’s what I meant, sorry :bowing_man:

Ah, there it is. That makes sense. That’s most likely the reason my backups take so long, I’ll do what you mention; do a backup with all snapshots and then get rid of a lot of them in my current project. Let’s see if that fixes it.

Thanks a lot :heart:

✎ Now that I think about it, is it possible that it also slows down because of the hard drive? I tried making a backup in it and another one in my desktop and it takes longer if I make the backup directly in the hard drive…

It definitely could, hard drive speed will be of large impact in how long backing up, forming large Scrivenings sessions, compiling and rebuilding the search index can take. These operations all must load and close many files, sometimes hundreds if not thousands. In general a modern SSD will far out-perform a spinning platter disk, but there are other factors as well, such how long ago the disk has been defragmented (something that is of no use on SSD). Or how old the SSD is, as they do get slower over time, and can slow down a lot more than old disks when they get past 85% capacity. Lots of factors!

1 Like