Large documents: Scrivener has performance problem

Unfortunately, Scrivener has a clear performance problem with larger text documents compared to other apps of a similar nature.

Specifically, I have a notes document where I write down all sorts of things in a single place. In the course of time this document has grown and includes now 14’000 words. Not so much. But the writing is heavily delayed (only in this document). Enter is executed only after about one second.

As far as I understand, Scrivener stores the content for each entry/document in a separate file. That is why overall performance is not affected if you have a large number of documents. But if one document is long/large, this has a significant effect.

This is really a pity. Is there really no way to make this better in a next version? Nevertheless, of all the apps of this type that I know, Scrivener is the most reliable and the one with the widest range of features that I need :slight_smile:

Yep. Not news. That’s pretty big, and depending on your computer (CPU, Memory, etc.) impact varies. It’s really only a “problem” when one creates such a monster file and expects it to work in a way that it won’t.

Monster file? 14’000 Word? Text only? :slight_smile: And yes, I would actually expect Scrivener to do no worse than TextEdit.

Up to L&L to comment I guess, but you are using Scrivener not as it was designed to be used. “Caveat emptor”, as they say.

Mh, a legal principle that applies mainly in the Anglo-Saxon world and is rather foreign to the rest of the world - for very good reasons :slight_smile:

Just so I know, what does L&L say? What is the maximum number of words in a document? I can hardly believe I am asking such questions :rofl: :joy:

But thank you for telling me. I actually did not know that.

Wonder how Scrivener would handle importing this…

7 million words and counting

1 Like

Give it a try and report back! :wink:

Maybe I’m wrong with my assumptions and what I notice!

1 Like

I have much smaller texts that cause sluggishness in Scrivener, so I am too scared to even try. :joy:

1 Like

After the hint from rms I had a look in the manual, and found this

“The core concepts of Scrivener are these:
— You can break the manuscript down into sections as large or small as you like, and work on it in any order.”

If “sections” means documents, there are no restrictions. :slight_smile: Or am I wrong?

Just so you know, there are so many other things on your computer that affects performance on saving (file system, network connections, etc.) along with how the rest of the computer behaves. I’m not saying that Scrivener may be completely “innocent” with large files, but pointing at one thing and perhaps expecting a fix may not be reasonable.

At minimum what I would do if looking at your situation would be copy (with a project name prefix of “test” or something to distinguish from working copy) this project into a new folder (a folder local to machine and not in a cloud-synced folder), and on this test project see if the performance does not meet your expectations.

If not then use the Menu:Document → Split feature to split the file into say 5 parts and see if performance is affected positively. If yes, then a clue. If no, then perhaps it’s the machine. After that, go where the evidence points, I guess.

1 Like

Yes, thank you, those are good suggestions. I will try that and report :slight_smile:

I have a M1, so a pretty fast mac. What I already tried is to copy the text into MacJournal (similar to Scrivener) or TextEdit or Word. No problem anywhere. This makes me think that Scrivener is the problem.

1 Like

My experience mirrors yours: Scrivener chokes on documents far earlier than other apps do on my Macs.

Splitting into smaller chunks can help, but then I see a hit in performance when viewing or editing multiple documents in scrivenings mode.

There’s a distinct gap between theory, ‘a document can be almost any length’, and practice, ‘keep documents fairly modest in length’.

1 Like

I just tried a few things… When the Scrivener file is stored locally (not iCloud), everything works faster. It’s still not perfect, but it’s better. However, having long texts of other apps on disk or in the cloud makes no difference at all. So I conclude it’s at least partly a Scrivener problem.

I now have to decide whether to leave the Scrivener file in the cloud for security reasons, or copy it to disk for performance reasons, mhh.


Thanks for that. Must this file be inside Scrivener? Is it part of a document that you compile into a finished document? If not just keep it in, say, ~/documents/scrivener/[whatever the project name is and where the *.scriv project is stored]. edit with whatever editor you prefer and like.

“Must”, well, I want it to be in Scrivener because that is my main app to write and to collect research results. In this one file is my whole life :slight_smile:

No, it’s a kind of diary, where almost every day a few lines are added. It’s never finished…

OK. then I assume it’s in the Research Binder. Just trying to nudge you into a solution that will eliminate frustration. By keeping it in the same Mac folder as the Scrivener project and editing with a preferred tool will eliminate that frustration and you won’t lose it. Maybe even putting a short cut to it from your desktop as being so important, removes I think frustration which will probably never be mitigated by Scrivener. You’ve already established that Apple’s iCloud is part of the problem. Frankly Apple’s iCloud is known to be problematic. and unreliable for a lot of people!

Your diary is more important than letting these little but solvable issues get in the way. IMHO.

You mean the research folder versus the draft folder? No, I have all my folders at the same level as these folders but not in them. Ok, I will try the short cut.

May be. But no other app I’ve tried has a problem with it.
Anyway, tanks for your time and thoughts :slight_smile:

Scrivener documents are stored in rich text (RTF) format, even if the content is plain text. Find that document inside the project, and check the size of it compared to its size outside of Scrivener (before you imported it). Right-click on the project and select show package contents, search for .RTF in Spotlight (only inside the folder), sort by size, and find the largest document.

I don’t see any reason to say Scrivener isn’t meant to include 14,000-word documents.

There is no maximum.

You are not wrong.

Is the project on your M1’s local hard drive? Is it in an iCloud or Google Drive folder?

It’s only prudent. On the other hand, I’m not sure breaking it into 5 chunks should necessarily perform better (in scrivenings mode) than leaving it as a single document, as there’s bound to be overhead associated with displaying multiple files as if they were one file.

It’s on the disk either way! But it may be that Scrivener and the iCloud sync service are interacting in some weird way. (Seems unlikely, but still.)

I suspect you got better performance when it’s not in an iCloud folder (which, again, is on your hard drive) because the iCloud version has smart sync turned on. Turn it off for the folder where you keep projects. That’s a must for Scrivener projects, even if it doesn’t improve performance.

When you made a copy outside of iCloud, it became a fully disk-resident version with no “smart sync” to muck things up.

Other apps don’t have a Binder full of other files, a scrivenings mode, etc.

Keep it in Scrivener, but move the project out of iCloud and/or turn off the online-only/smart sync feature.

1 Like

Thanks for your detailed answer.

Right! Now that you mention it. Everything in the macos Documents folder is on the disk, but syncs also to the cloud. Documents that are not in that folder are on the disk (of course) but will not be synced, correct?

Macjournal does more or less the same thing as Scrivener. (But is faster at everything) Some features are better, some are worse. If I wasn’t using Scrivener, it would be Macjournal for sure.

1 Like

Not necessarily, if iCloud’s “optimized storage” feature is enabled.

1 Like