Beachball delays

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?

1 Like

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?

1 Like

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

1 Like

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:

  1. Export the document from the project, using RTF format.
  2. Create a new blank project.
  3. 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.

1 Like

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.”

1 Like

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.

1 Like

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?

1 Like

I don’t have that much of a wish to self-inflict misery.

Sorry,

3 Likes

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.

2 Likes

I learned that after struggling with images in projects, early in my Scrivener journey.

1 Like

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.

1 Like