I don’t know if this is helpful or not, because I cannot reproduce it reliably, but I often find Scrivener at 100%+ CPU during normal operation. When it happens:
It sounds like you are monitoring Scrivener in Activity Monitor, so what I would do is use that same tool to sample a report of what Scrivener is actually doing when it is demanding so much CPU. Since it seems stuck it should be fairly easy to catch it. Next time you see it happen, click on Scrivener in the Activity Monitor list, and use the View/Sample Process… menu command. That will take a few seconds. When it completes a dialogue will appear with a bunch of information and a button to save it all as a file. Do so, and send me a copy via PM as an attachment, or to our email address.
Also open up Console.app and make sure you aren’t getting any warnings or errors that look relevant while this is going on.
I also had issues with Scrivener at 100% CPU / spinning beach ball / non-responsive. My issues were related mostly to manipulation of jpeg images. Insert / Image from file would reliably cause the beach ball to appear. Also double clicking on the image and attempting to scale, or center the image would also cause the problem. I have collected the console logs and the sample of Scrivener from the activity utility. This has been somewhat painful as my document has 100 images.
I would create small copies of the images and put them in the Research part of Scrivener and then use Link to external file in the project when it is time for compilation.
I am experiencing this more and more. I thought it might be an issue with DropBox - so I moved my Scrivener Files out of DB. I am attaching Sample CPU Process reports in hopes that you might see something I might look into. It is getting to the point where Scrivener is unusable.
I will add my project has some images - they are NOT in documents that I am editing - but I am wondering if there mere existence could be causing any background issues. Thank you in advance for any insight that you may have on this matter.
I doubt that’s of any concern, that isn’t how the relationship between Scrivener and Dropbox works. Really you can better think of the relationship between the two as there being two different programs that read and write files to the same rough area of the drive. Imagine if you have a file viewer on one side of your screen and an editor on the other. Whenever you save in the editor, the viewer updates and shows you the result. At a narrow technological level, the relationship between software saving files and Dropbox reading and uploading them is pretty much identical to that. It’s more likely we’d see the opposite, where the writer is adding data so fast or in a way the viewer doesn’t expect, and causes the viewer to lag trying to keep up, or malfunction. But that is where our analogy kind of breaks down anyway, since Dropbox is a viewer only in a very basic sense. It really doesn’t care what the bytes are, just that they are different now and need to be uploaded to the server.
Now if Scrivener were something that read changes from the disk in real time, then in theory it could get jammed up if something else changed a bunch of its data beneath it, but it’s not. It blindly writes to the disk, and thus it is almost impossible for a “viewer” to trip it up.
If the images are not stored in the documents, then it is unlikely they are of any impact to performance. Stuff that might make them factors are viewing large quantities of them on a corkboard (consider disabling image thumbnails if you do that a lot), or going through them one by one in the main viewer. But if you don’t do anything to view them in any way, they might as well not even be in the project for all of the impact they don’t have.
The one red flag I did see in your “slow down” sample is that Scrivener peaked at 3.9gb of RAM usage. There is definitely on the high end, and could indicate you’ve done a lot of media import or browsing recently. It could also indicate you’ve compiled a particularly large project recently. With numbers like that, I’d encourage being a little more wary of usage, close the software more often between sessions, and after working in very large projects. It’s generally not necessary to pay attention to things like that, but 4gb isn’t typical for something that isn’t doing 4k video editing or similar. And depending on how much RAM you system has, some of that slow down may have been excessive disk swapping, to compensate for a lack of sufficient physical RAM to keep everything running.
So what I would do is leave Activity Monitor running on the RAM tab, and keep an eye on Scrivener’s usage as you go about the session. It should start out with nothing open, pretty minimal (maybe a bit less than 100mb). If you open a large project, it may spike up a bit, but pay attention to it whenever you do something that you feel might involve a lot of data. Loading huge Scrivenings sessions and so on. What you’re looking for are cases where something causes a large spike, and then that memory use is never reclaimed normally. Ideally the memory use should always go back down to roughly how much it was using when the project was opened, it may sometimes take a minute or two to get there, but if it goes up, and just keeps going up, there could be a memory leak and that’s ultimately what is causing your system to slow down.