When is a Scrivener project too large?

I prefer to have one Scrivener project in which I organize all of my projects. I tried separating them, but I come back to work in the central project anyway. Currently that project size is 190MB, which does not seem to me to be so large, but it does take quite a bit of time to save and backup on closing. I have not timed it, but I am quite sure it takes longer than 2 mins.

So my question is is 190 MB too large for a Scrivener project?
Are there plans for future updates to accommodate those who prefer to have only one Scivener project?

I do not sync the central project to any other device. It lives on my laptop hard drive and I only work on the project from my laptop.

Backing up a project is the first task to be affected by project size, because it involves making a complete copy of the entire thing. Most editing operations only load the current document(s) being edited.

Two minutes to back up a 190 MB project seems a little excessive. Are you backing it up to the local hard drive, or to removable media like a USB stick?

To answer your original question, a project is too large when you think it is. That is, from Scrivener’s point of view you are nowhere near the limits. The program has been tested with projects well into the GB range. But only you can decide how to balance the tradeoff between convenience and performance.

Thank you for answering my questions. I am relieved to know that 190MB is not even close to being a large file for Scrivener.

Regarding your question if I am using a USB stick, the answer is no. But here are the details:
Before I posted my question today, I read another post warning that the Scrivener files should preferably be saved on the hard drive and the backups (.zip files) should be either on an external hard drive or on Dropbox or both. My setup was exactly the opposite, so I made the necessary changes. Now the main Scrivener file is on my hard drive (not on a USB stick, nor in the local Dropbox folder) and the file is backed up on closing to Dropbox.

So with this new setup, it did not take so much time today to close and backup the file, but also today I did not make many changes in the file which might be the reason everything was so fast. This time I paid attention to the time it would take to close the file and back it up. It was less than a minute, which is reasonable. But I do not know if things will change if I work on the file quite a bit.

It shouldn’t, since:

  1. auto-save (a few seconds after each time you pause in typing) saves the document you’re working on at a given time, so that doesn’t have to be done when closing the project
  2. the zip backup is everything, whether you made one edit or a thousand
1 Like

I think you are getting closer to a good setup. I’ll tell you what I do and recommend. You can consider:

: All Scrivener project reside as subfolders (actually are macOS “packages”) in my local drive ~\Dropbox\Scrivener. Being in this location means that

  • access time is fastest possible. Saves are set for every 2 seconds of inactivity
  • picked up in my computer’s backup (TimeMachine, see below)
  • most importantly, synced to Dropbox so available also on both macs and both iOS devices

: All Scrivener backup files (zip files of entire project) are kept in the folder on local drive ~\Backups\Scrivener. I ask Scrivener to backup automatically “compressed” on “Project Close” and I keep 25 most recent backups (configured in Preferences). Being in this location means that

  • creation time is fastest as possible, but of course making a compressed zip takes a little extra time vs. not compressing, but it’s one-off on close of project so time not critical.
  • picked up in my computer’s backup (TimeMachine)
  • I don’t put these backups to Dropbox because Dropbox is great for synching but not for “backup”. If the backups get corrupted, deleted, etc. then that flaw is synched and poof, backup gone.
  • Some prefer putting these backups in a separate Dropbox folder (separate from the projects) and I guess that ok but I would only do that in addition to keeping a local copy out of Dropbox, but I don’t need it as I have the TimeMachine backup.

: Backup of project files and the entire Mac are essential. I’ve never owned a computer, esp. laptops, that didn’t suffer from a failure that required restore from backups. I follow the 321 backup strategy. See details on numerous 'net articles. 3 copies on 2 different types of media, 1 of which is in a remote location. For the latter I use the commerical product BackBlaze, and I backup with TimeMachine to connected USB disk and networked file server.

Re your issue of 190 MB taking 2 minutes to create a backup which I presume is a zip file. That does indeed sound excessive. You could turn off compression and see if that goes faster for you.

My biggest project is 220mb (size of macOS package) of about 300 pages with lots of png images but not very many Research files. Takes about 6 seconds to make a backup zip on my 2017 iMac (has lots of memory).

1 Like

My main project is 4.22 GB and it backs up in less than a second (unzipped) but over 6 minutes when zipped! The zip file is 4.16 GB so not sure of the benefits of zipping tbh.

1 Like

the benefit of a zip is reduced file size. if that not worth it to you then fine. i am pretty sure Scrivener uses system zip software so if you have complaint about excessive time to create a zip for this many bytes, best to contact Apple or buy a faster machine. :wink:

The zip default option has three important intentions:

  • It makes it impossible to load the backup in Scrivener directly. While it should be common knowledge that opening and editing backups directly is a bad idea, it isn’t. Putting a step in here where one must create a copy of the backup, by extracting the contents of the zip file, nullifies the risk of unintentionally destroying one’s own safety net.
  • Many people prefer to locate their backup folder in a location that is automatically uploaded to an off-site server, such as using a cloud provider or online backup service. The networking overhead of sending many files is significant, such that uploading one 4gb file will take a lot less time than uploading several thousand files of the same total size. For smaller projects, it also makes for a backup format that is much more portable, capable of being attached to email and so forth.
  • In conjunction with online backup or cloud services, is makes restoration less complicated, since you are only downloading one file. This is important because there is an inclination toward misunderstanding that a Scrivener project is a folder of many files. Just searching this forum for “my project backup is blank” will reveal how many people merely download a .scrivx file all by itself from a server, thinking that one file is all they need.

So as a default setting, there are very few downsides to the zip option. The only time it really becomes problematic is when project sizes grow to a point where the time it takes to zip compress is inconvenient. Given the second point above, if one is uploading their backups automatically, it still probably has a greater net overall time expense to upload .scriv folders, even with the wait time for compression—but if you have a fast connection or you don’t care how long a background uploader takes and just want to minimise closing durations, disabling the zip option is fine.

Overall I would say having it off is a more advanced setting, given all of the above, but the setting is there for good reasons.

2 Likes

Ok, there may be a bit of a misunderstanding here. I haven’t complained about anything and my 2 year old iMac is plenty fast enough. I merely stated the times that the 2 backup methods took.

As for file size, I’m not sure how big an advantage reducing a file from 4.22 GB to 4.16 GB is.

1 Like

Yes, I think there is a misunderstanding as I didn’t interpret anything you said as a complaint, but a request for information on any advantages or disadvantages to the zip option.

The “complaint” was referring to rms’s post above yours, Amber.

1 Like

I probably misunderstood. My intent was to point out that time to zip, if not useful, is not useful. @kewms subsequently pointed out a key point of value which I forgot about but in fact totally agree with–that being a zip backup prevents people getting confused about which version is the “production/in-progress”. I think that important.

Ok, I get what you mean although I have only backups on iCloud as I work on the projects on my hard drive.

On another note, my 4.22 GB project is now only 8.7 MB after I emptied the trash. There were a load of image files that were nothing to do with my project. No idea how they got in there!

That said, the zipped backup file is still 7 MB so not a massive size saving.

Just to give you an update. I moved the main Scrivener file on my hard drive and now the back ups are zip files on Dropbox. I need to have the files in Dropbox for peace of mind in case something happens to my hard drive or the external hard drive which is connected to my mac all the time.

So far the closing time is definitely under a minute.

But I still notice that creating a link in a document is not instantaneous. There is a bit of a wait until the new document appears. I wonder if this is because of my computer’s old age (mid 2015). I used to think that it is because of the size of my Scrivener file, but now I am thinking that this cannot be the reason.

1 Like