I have been a loyal user of Scrivener for at least a decade, but I am getting quite frustrated with how slow it runs on my MacBook. I am using version 3.3.6 on Sonoma 14.4.1, and I have just one small project open. The activity monitor shows Scrivener with the highest CPU time and GPU time. Is there a solution for this?
The current version of Sonoma is 14.6.1. It wouldnât hurt to update in case thereâs a Mac OS issue contributing to this.
How small is the project? Is it just text, or does it also include research materials like web pages? Is it stored locally, or with a cloud service?
Under what circumstances do you see the beachball? Whenever you open the project? When you open a specific document? When you try to use Scrivenings mode? Something else?
If you open the Tutorial project from the Help menu, do you see the same behavior?
What other programs are you running when Scrivener appears to play beachball with you? For example, are you running a web browser at the same time and if so how many windows are open and how many tabs in each one.
One the Scrivener front are there PDFs in your project and are they âopenâ? Iâve see high CPU usage after opening (and then closing) a PDF saved in my Research folder from within Scrivener.
How much disk space is available (especially for paging and swapping if you run other stuff)? What is the disk? Physical hard drove? SSD? Are there disj faults being logged?
How much RAM is there in your MacBook? It is Intel or Apple Silicon based?
So many questions. My normal work environment is Chrome running with lots of tabs open, Zotero open, and Scrivener running. I have worked this way for years without difficulty, but lately, I type two wordsâbeachballâtype six moreâbeachball. Really unacceptable. I have 40gb of open disk space and have 8gb of Ram. Typically this has been plenty for many memory-hogging projects.
The good news is that I took kewmsâs advice and upgraded to Mac OS 15.0, and things seem to be a little better but not entirely fixed. In any case, thanks for the suggestion. If you have any other ideas, Iâd love to hear them.
See my questions up above.
Also, what is Scrivenerâs autosave interval set to?
Interestingly, the problems do NOT occur with the Tutorial. I note that the Tutorial project is only 5 mg, whereas my project is 100 mg, perhaps due to there being several large photos embedded into the document. So what does that tell you?
In my project, anything reinserting the cursor, tapping on a menu, typing, can awaken the beachball. I usually work in Dropbox, but even turning off syncing does not help. I tried changing the save time to 10 sec (which seems like something I shouldnât have to do) and that didnât help.
And, as I have said before, none of this happened for many previous years of Scrivener use.
Again, any suggestions would be very appreciated.
At this juncture would be good to answer all the specific questions above by @kewms
Here are my answers to all the questions.
How small is the project? 100 mgs
Is it just text, or does it also include research materials like web pages? It has links out to web pages, and several large photos embedded.
Is it stored locally, or with a cloud service? Locally and backed up in Dropbox but the problem persists when syncing is turned off.
Under what circumstances do you see the beachball? Almost any action, typing, reinserting the cursor, scrolling, or touching a menu will be greeted with the beach ball.
Whenever you open the project? Yes.
When you open a specific document? The project is basically a single document.
When you try to use Scrivenings mode? Yes
Something else? not that I have noticed.
If you open the Tutorial project from the Help menu, do you see the same behavior? NO, which sounds like an interesting clue. Is it simply the size of the project, 100 mg versus the tutorialâs 5 mg?
Thanks for your help.
Chrome is also known to hog memory. Whenever I need Chrome extensions, or the full features of Google Meet for example, I use Vivaldi. It uses Chromeâs Blink website rendering engine, but a proprietary UI. The developers founded the Opera browser 20 years ago but left when Opera switched to Chromeâs Blink. They have been reviving the classic Opera user experience.
What dfo you mean by that statement? Are you saying that your project basically consists of a single binder document with embedded photos and links?
Yes. One of my attempts at a solution was to create a new project that contained only the document I was working with at the moment. That document is text and embedded photos and links. That strategy did not help.
Itâs quite likely then that the problem is in that one document you are working on right now (especially if that one single document is 100mb, I wasnât quite clear on whether that is the case, or the larger project it came from, but if that is the case then the problem is fully discoveredâthatâs way outside of Scrivenerâs designed scope of optimisation). As a way of testing a couple of ideas:
Splitting it down further
If your document has styled headings in it (having used âHeading 1â, âHeading 2â and so forth), then you might be able to get to a good point with this simple checklist:
- Export the document from the project, using RTF format.
- Create a new blank project.
- Use the
File ⸠Import ⸠Import and Split...
menu command, and set the option to split by the documentâs outline hierarchy.
But otherwise, if there is anything formulaic you might split by, such as using â------â to mark sections, or the word âchapterâ here and there, youâll see tools for such as well in that dialogue box.
Without images
In this test, copy the entire document and paste it into a blank test project using the Edit ⸠Paste and Match Style
menu command. Does this increase performance?
In both cases I would suggest restarting Scrivener before testing to see if the method used speeds things up.
To be clear, both of these are diagnostic tests. Iâm not actually encouraging you to blow away 100% of your formatting and delete all of your images. That said, the first option of splitting long documents up into smaller chunks absolutely is a good way of using Scrivener, as you knowâmaybe in this case it just needs a little more.
If the problem is the images though, there are things that can be done to speed up processing.
Youâre in good hands with @AmberV, so Iâll step aside. Iâll just reiterate what others have said: 100 MB in a single document is not âsmall.â
Just on the subject of size, I have had a quick play around and made a project that totals 427MB in size with many images.
It runs just as quickly as a new blank project for me.
Perhaps a few pertinent points:
M2 Max
32GB Ram
2TB SSD
34 Safari tabs
Mail and a couple of other apps open.
All the images are via âImage Linked To Fileâ
I suspect on an 8GB system, especially if it were an Intel and even worse if it had a spinner, Iâd be in treacle territory. 34 tabs in Chrome would certainly be hogging some resources.
Itâs not project size, but document size, that makes the difference in most cases. What happens if you mush all of that into a single document? And import the images?
I donât have that much of a wish to self-inflict misery.
Sorry,
That, and âAll the images are via âImage Linked To Fileââ makes a world of difference.
Just to put it into perspective, 100mb of data is about 50,000 pages of printed text at the file level. Thatâs a good floor to ceiling bookshelf of information being processed between every keystrokeâfor obvious things like smart quote pairing and spell check, and myriad things most people would never think about (like how the viewport has to be drawn and then redrawn to get around bugs in the text engine). And thatâs how much is being saved every time auto-save ticks over.
I learned that after struggling with images in projects, early in my Scrivener journey.
After considering your suggested tests, I simply removed all the photos, and it works fine. I will have to modify my work pattern.
I write online articles that often include photos. I like to insert the photos into the document so that I can get a sense of what the final layout will look like. Each article is a single document, and as I now understand, if the document gets too big (due to the images), I risk getting the beach ball. If there is an easy way to avoid this, I would love to hear it. If not, I can work around it.
Thanks to everyone for the help.
The easiest solution would be to use linked images and have both low res and high res versions. The low res versions let you see what youâre doing while you write, while the high res versions are for publication. See Section 15.6.4 in the manual for a more detailed discussion.