It costs me several seconds to wait until I could continue editing my document. The document is now 20 MB. What’s the problem?
First port of call is to check to see if you have enough RAM available, or if there is some process using an excessive amount of CPU. Have a look at Activity Monitor to see if that helps diagnose the problem.
I know this may seem pedantic, but what do you mean by “save” and “document” here?
You can trigger an automatic backup (what you mean by ‘saving’?) using File->Save or the keyboard shortcut “CMD-S”, which creates a complete copy of your project (AKA your ‘document’?) and stores it in a folder designated in Scrivener->Preferences->Backup. This will always take a few seconds, especially as your project grows beyond a couple of megabytes.
If, on the other hand, you mean the auto-save that happens when you pause for two seconds, then this delay is something unexpected. It should only be saving changes to the document in your project which you had just been editing. Typically these documents in the binder hold a few hundred, or a few thousand words at most, so the auto-save would barely be noticeable. Do you have an images embedded in your document? That can cause a slow-down in the auto-save.
I think I’ve pinpointed the cause of the problem. When I ticked “Take snapshot of changed text documents on manual save” option, then, it causes me to wait about several seconds to save the document. I think this is a problem that should be fixed.
Taking a snapshot saves an additional copy of the document(s), allowing you to roll back to that earlier version if needed. Save + snapshot takes longer than a save alone because Scrivener is being asked to do more work. So I’m not sure what the “problem” is here, or how we would go about “fixing” it.
When you say your “document” is 20 MB, do you mean your Scrivener project, or the particular sub-document you’re working on? If the latter, realize that 20 MB is quite large for a single document. Splitting it into chunks would probably both help your overall performance and make it easier for you to work with.
Katherine
kewms, it’s definitely a problem according to my experience in programming.
20 MB is the whole project and the document I am working with is only 650 words. Well, I think, even if it’s 20 MB, it should not take so long (as veteran programmers should know how to workaround this issue), let alone it’s only 650 words. I am sure it’s a problem if this issue happens to everyone.
@AmberV, please help.
I think Katherine’s point is sound. When you take a snapshot, Scrivener is creating a new file on the disk (sometimes a couple of files and a new folder), this is going to add necessary and unavoidable overhead—we’re talking basic hardware limitations as well as OS and filesystem architecture here—several metaphorical miles beneath where Scrivener is operating. The only way to really solve mass file creation and other I/O bottlenecks is to invest in high-speed SSD or RAID drive technology (assuming of course that the rest of the system is not overloaded).
Speaking of which, where is your project stored? If it is not on your fastest drive, maybe consider moving it there. Using network shares and flash drives will, of course, massively increase all I/O operations (but particularly the output, with Flash drives).
As Robert points out, another option that can dramatically slow down Cmd-S is if you have the option enabled in the Backup preference pane to back up the project at this time, and especially so if you zip compress the backups.
Overall though, I would not say this is a major efficiency issue. Hitting Cmd-S in Scrivener is more like something you would want to do every few hours—especially if you have snapshots and backups tied to the action. It’s not at all like in a normal word processor, where if you aren’t slamming Cmd-S every five minutes you risk serious data loss. In Scrivener, the project itself is kept up to date very close to continually. Whenever you pause for two seconds all pending changes are saved to the disk (and typically, instantaneously). Thus, Cmd-S is something you don’t need to do frequently, and as such, I don’t really see it as an issue if it takes several seconds to carry out the tasks you’ve asked it to.
AmberV, thanks for all your previous help! But I cannot agree with you this time.
It’s not an efficiency issue if it’s a 200MB file but it’s only 650 words which amounts to only about 20 KB and I do use an SSD. I cannot accept this performance. It’s NOT an era for single-thread programming any more. There should be some solution which will make Scrivener perfect and that’s probably one of the big improvement in the next version.
A mere user here, not an official tech-support wallah, but if you’re having speed issues saving a 650-word file in a 20-mb project with an SSD, you’ve got other problems somewhere. One of my current projects is 65 mb and there are dozens of 4000-7500 word files, and I have no speed problems when saving even with a relatively creaky 2007-era MacBook Pro, with 4mb of ram and a 256-mb aftermarket SSD.
Could you take a sampling of Scrivener while it is working during the save operation, using Activity Monitor? Feel free to send that to our tech support address rather than posting it here, if you wish. I would myself say that a several second progress bar after a good amount of work, with snapshots enabled, isn’t too out of line, but I’m not sitting in front of your computer looking at the actual data schedule to be written and comparing that with similar performance requests in other programs (including Finder). So maybe you’re seeing something way out of the ordinary, I don’t know.
Multithreaded saving and loading is not a trivial thing. I believe Microsoft has a patent on some horrifically complicated three-way cycical packet system that they use for Office, but that’s all a bit out of our league. 
To be clear, we’re just using OS X’s public file system calls to work with the disk.