Love Scrivener (3.4 build 16639 on macOS 15.5).
Yes, I do have one or two large graphics in my latest Project, which is 401 MB in size.
But would they account for the beachball for several seconds each time I (by now after 40+ years) unconsciously/automatically hit Cmnd+S after most (important) additions/edits, please?
Are the large graphics in the document thatās currently being edited?
Have you enabled the option to backup on manual saves? (On the Scrivener ā Settings ā Backup tab)
@kewms; thanks!
How do I reveal the graphicsā sizes so that I might post them here and see whether they could be the cause, please?
(The saves always - ALWAYS - do finish. But take sometimes up to 10 or 30 seconds.)
What I would recommend is splitting the document so that the graphics are in separate Binder objects, and seeing if that fixes the problem. The absolute size of the images is less relevant than whether theyāre actually being loaded by the editor.
More generally, 401 MB isnāt particularly large for a Scrivener project, but itās very large for a single document within a project. We recommend working with much smaller chunks.
If you have only one or two large graphics, and a 400mb project, then those are some very large image files indeed! Or maybe you mean you have thousands of images, but only one or two are large.
As for checking their size:
For the large one(s), I would recommend dragging them into the binder from the editor. This will copy the image there, so now for the moment the project has two copies. Remove the copy in the editor, and with the cursor where it was, use Insert āø Image Linked to Document to pick the image. I recommend enabling the Link to images dragged from binder into editor option, as well, in the Behaviors: Drag & Drop settings tab, as using that menu is a bit cumbersome in my opinion, especially if you have a lot of images in the binder.
Now instead of 200mb of text being saved (because yes, to store an image inside of a text file it has to be converted to text, itās one of the most inefficient ways to store an image), youāre only saving maybe 20 or 30 characters that reference where the image is in the project, and the scale it should be displayed at.
But to step back a bit to that Finder stage, if these really are ~200mb images, you probably do not need all of those pixels in Scrivener at all! Keep the originals somewhere, sure, maybe for print, but creating a smaller compressed version to work with will save you a lot of trouble. Even if you saved it as a full-page image at art-quality 300 DPI without any compression, it should be about a quarter of that size. So unless youāre working on movie posters in that project, you probably donāt need files like that in the writing space.
Amber,
About a dozen.
I have just gone through the entire Project and:
Thanks
Yes; Iāve done all those that way.
Of course. Thanks. I can see that. Yes - done that too.
Now, theyāre all much smaller (scaled down) images. None inline. All in the Resources Folder.
But this Project can still take 30 seconds to save!
Thanks @kewms!
Yes - theyāre all in Resources now; and linked rather than inline - per Amberās kind directions.
I donāt think so so far. But Iāll experiment over the weekend and report back here, if I may
Appreciatedā¦ 
.
Just a thought. Boot into macOS āsafeā mode and with the Disk Utility do a āFirst Aidā on the drive holding your data. Maybe something going on with the disk? Prudently, ensure a recent TimeMachine backup has completed fully before the āfirst aidā.
This is one of those āoh of course, thatās itā type things, but the project isnāt on a network drive, like an NAS, or file sharing from another computer?
Thanks, @rms. No, the disk is OK!
Amber - good questions, of course:
No. Neither.
OK. But are you sure without the check?
I ran Disk Utility > First Aid. I also do multiple clones and check my hard drives. Iām obsessive .
Glad to see your disk is okay. Thatās a good thing to check, as long file system lags have been the harbinger of total disk failure for me on a Mac, more than once. But typically when that happens, all manner of things are slow, like loading folders in Finderāif you ever see that happen, back up everything immediately.
So something we can do, since this does involve Scrivener pausing for an extended duration, is gathering a āsampleā of what it is working on, while that wheel is spinning. To do so, first load Activity Monitor, and use the search bar to get Scrivener easily available in the list. Then proceed to save, and as soon as it starts spinning, switch back as fast as you can, select Scrivener in the list, and use the View āø Sample Process... menu command (or keep the keyboard shortcut in mind).
This will run for a few seconds, and will produce a huge amount of information in most cases. Use the Save... button in the top right corner to save it to a file, and attach that to your response.
This is provide a fairly complete picture of what is going on in that moment. Whether it is useful or not depends, but it might give a clue as to what is making things so slow in this project.
Amber,
Thanks. Yes. No other signs - that Iāve seen. I run EtreCheck Pro and Onyx once every few weeks or so. Nothing.
Yes. Appreciated. Have Messaged you with a zip of what it sampled.
I will say that the Saves seem to be taking less time now. Backup is still often much longer.
As I say (fingers crossed) no other signs of trouble - anywhere.
Your help very much appreciated!
All right, Iāve had a look at that, many thanks for sending it. There are a lot of image operations being run, which does mean there are still some images that arenāt linked. Something I would try at this point, as an experiment, is a negative test to see if this is even the right track at all. If this doesnāt help, then there is no need to continue pursuing images as a culprit.
Save As... on the project to make a disposable copy.Edit āø Find āø Find by Formatting.... Set the search mode to images, with no other criteria, and start walking through. At each new document that contains an image:
The idea behind testing manual save after each document is wiped, is to ascertain whether the saving time is gradually getting better, or suddenly goes from long to instantaneous. If the latter happens, then you can probably stop this procedure and focus on whatever was going on in the last document you cleaned.
Thanks, Amber!
There were. Sorry. They were all small (thumbnail) images, which I thought would not affect things.
But - as you say - they may well still be causing the long Save.
So I went through every document, CTRL-clicked on each and every image to make sure I could definitely always see āConvert to Embedded Imageā.
There are none. Doesnāt that mean that every image is now only in my Resources folder and invariably properly linked rather than inline?
That does seem to have speeded things up.
Could as a few thumbnails which were embedded have been causing this Amber?
May I suggest that I try this for a little while and then get back to you here if things are still slow - after working my way through your steps 1 - 4 (1, 2, 3), please?
BTW not sure what 4.1 and 4.2 do - unless itās to delete any images to see if there was one causing the slowness.
Two more points, please:
I correct it by deleting back from the āEā, save it; but it re-appears on my next open.
Thanks again. Iāll come back here soon
BTW not sure what 4.1 and 4.2 do - unless itās to delete any images to see if there was one causing the slowness.
Paste and Match Style strips the text to plain-text and removes the images, so yes it is an efficient way to remove all of the images in a section, which we then follow up with a test save to see if it was that section that was making things slow.
This is course why this test is being done on a disposable copy of the project. Itās merely to gauge whether or not this entire track of looking at images is worth continuing to look at.
May I suggest that I try this for a little while and then get back to you here if things are still slow - after working my way through your steps 1 - 4 (1, 2, 3), please?
Sure, but again like I say, if none of this has anything do with images then it would be a better use of your time to determine that first, rather than dividing your time between a task that presumes it is the problem, with a task that challenges that presumption.
If you look up the shortcuts for the Find Next Formatting, Select All and Paste and Match Style, you should find this experiment can be done rather quicklyāat least to a point where you might determine things are gradually getting faster when you save.
I correct it by deleting back from the āEā, save it; but it re-appears on my next open.
I donāt know about that for sure, but it does kind of sound like a phantom list from what you describe. The usual methods for stripping out formatting and reapplying it should suffice.
Ambre,
Thanks!
Understood .
I follow you 100% Yes - I can see that.
In fact, since I made all the images in Resources and only ever linked to from the main text I havenāt had a slow Save. Twice in an hour the beachball for just a couple of seconds.
And Iāve been testing with a variety of edits to see if any one was more āprovocativeā (of a long save) than any other.
I couldnāt see a pattern. Because so far today, every save is near instantaneous .
The backup still takes much longer, though.
Could that itself still be a good reason to do what you suggest?
Iāll keep working and if the Save time does start lengthening, Iāll immediately go to your suggested troubleshooting steps, thanks. At the moment, though Saving is almost instantaneous - except on Quit when it backs up.
For the other oddity, Iāve done as you suggested and deleted everything in the area of the āphantom listā and re-entered without any Style, then set to Title. Shall check each time I open this doc.
Your help much appreciated, Amberā¦
Okay! Sounds like it is a solved problem for now then. It probably was a few large images making things slow to repack into RTF, in that case.
As for backups taking a while, it isnāt usually something to worry too much aboutāI have some projects that take maybe half a minute to close because of that, and itās just something I know will happen and go do other things while it happens. It reflects how long it takes to duplicate the entire project and then zip compress it. If it gets to be a nuisance you could try turning off the zip option in Backup settings. Thatās usually the bottleneck, but it does also tend to save a lot of space on the disk.
