I normally work on Scrivener 3 on macOS, and when I close the application, the backup is incredibly fast for my novel. When I work on Scrivener 3 on Windows 11 and I close the application, I am waiting anywhere from 30 seconds to a minute for the backup to complete. Both machines use very high speed NVMe drives and have very fast processors and tons of ram.
Is there a way to improve said performance under Windows 11?
One thing to test would be to benchmark both systems using the same data. That is, rather than having Scrivener for Mac/PC generate the backup file, use the operating system tools to create and save a ZIP file from the project.
That will help you determine whether the bottleneck is Scrivener itself, or the local hardware.
The Mac is a Mac Pro 28 core Xeon with 256GB of RAM, and the drive speed is about 4GB/s read and write.
The PC is an AMD Threadripper Pro 3975x 32 core with 256GB of RAM, and the drive speed is about 4.5GB/s read and write.
I am a game developer by trade, hence the overkill hardware.
I zipped the project on both systems, each take approximately 10 seconds to compress to a zip file.
After a minor text change to the novel this is how long it takes to do the backup on save:
- Windows - 42 seconds (averaged over 3 runs)
- macOS - 11 seconds (averaged over 3 runs)
1 Like
how big is the file and the amount of video/pdf’s?. It did take about 44 seconds to backup up a project of 221 mb in size (zipped). Windows 11 only 64 gig of ram-Retired by trade
The tests by @Warbands point to a bottleneck on the Scrivener side, as zipping the project using Windows takes a quarter of the time compared to using Scrivener.
@GoalieDad, was your time to zip of 44 seconds determined by using Scrivener or by using Windows?
@JimRac it is interesting that outside of Scrivener the time to zip the project is basically the same on both my Mac and my PC.
I am curious what Scrivener is doing differently on PC compared to the Mac regarding how it is performing the backup.
My zip time was using scrivener as program. Did not try with outside zip program
It would be interesting data point if you could try it using Windows native zip facility.
I would do it, but all of my projects are relatively tiny. 
Best,
Jim
Okay, I just ran a few tests with one of my projects, which is a svelte 7 MB. Win10, SSD, 8 GB RAM
Windows zip 2-3 seconds
Scrivener zip 13-14 seconds
Scrivener’s definitely doing something in addition to the zipping operation.
It is saving the project first, for one.
I think I remember this as having been debated/investigated before.
If I remember right, @kewms or @AmberV had the logical answer.
There was indeed a difference, but it was logical for it to be.
Yes, there are two factors involved:
- It’s not just zipping the project from the disk like you are doing in Explorer. That wouldn’t create a safe backup for one thing, since the project is open and some files aren’t kept up to date continually on the disk, to speed up auto-save time. So it’s creating a full duplicate to a temporary location.
- The zip function isn’t Windows’, we can’t tap into that directly. It’s using the library for zipping that we have available, which may not be as optimised, or may be using different settings (high compression rate is slower, for instance).
As advised in the user manual, if you can afford the space usage and are running up against very long backup times, disable the zip option in the Backup settings tab to speed it up. The only thing to be careful of with that setting is to be wary of not opening the backups directly, as they will be ordinary Scrivener projects at that point.
2 Likes
Yup. I just tested by copying my project to another folder, and that took around 12 seconds, which exactly explains the difference.
@AmberV this gave me a few ideas on how to improve upon the backup slowness on Windows.
As mentioned previously in the thread my timings for a 140MB zipped ( 400MB unzipped ) novel are the following:
- Windows - 42 seconds (averaged over 3 runs)
- macOS - 11 seconds (averaged over 3 runs)
I then ran with the backup location being on a separate drive, in my case the drives are both identical NVMe running at 4GB/s.
- Windows - 25 seconds (averaged over 3 runs)
Turning off zip compression made my backup time INSTANT, it didn’t matter if the backup location was on the same drive as the original project or a separate drive. This was true for Windows and macOS.
I’d say if you can afford 5 times the size of your project in drive space (the default number of backups) and want it to be as fast as possible, I’d turn off the zip compression, of course with the warning given by @AmberV that the files in the backup location are ordinary scrivener projects now.
Hopefully someone will end up finding this information useful!
Perhaps only incidental to the OP, but related nonetheless, this is another reason why, when producing backups, Scrivener should timestamp the project’s .scriv folder as well as the project’s .scrivx file, with the same timestamps, identifying them all as a unique set, distinct from the source project. (It appears that the manual backup option to not zip somewhat does this, in that it timestamps the unzipped folder. That concept and approach should be applied to all backup processes, so that all bak containers, top level project folders, and also the scrivx files themselves have the the same timestamp in the same format appended to the base project name.)
This would make working with baks easier and safer, would make the accidental overwriting of projects much less likely, and probably reduce certain common support issues (though not the OP issue in this case.)
2 Likes