Infuriatingly Slow at Times

I’ve just recently discovered Scrivener and after testing it for about three weeks I bought the full version for Mac. However, this version is driving me up the wall with its lagginess and the wheel of death popping up mid-workflow about 30 times a day. I’m currently working on my Master’s thesis with around 15.000 words and when switching between items in the binder Scrivener is almost sure to freeze for up to 8 seconds.

I’ve checked with some forum posts and others seem to experience similar issues, but no one can offer a fix.

Scrivener also crashes when I try compiling the whole document, which is scary, as I have to hand in my work by the end of this month… I was wondering if my file is too big (542.3 MB), but I’m sure there must be far larger files than this.

Any advice is welcome. But I just wanted to get word out there in case it can be fixed in any way.

Most of the lag issues we see are caused by having lots of image data in the binder items. If the document you are compiling is half a gigabyte in size, that’s probably the issue with only 15k words (that is far larger than most documents I would guess—the Scrivener user manual by way of comparison is only 16mb or so, with well north of 250k words and hundreds of illustrations).

Best advice is to only make the graphics as large as they need to be to print—i.e. they are already the right size when you drop them into Scrivener. If you’re using the sliders to make them the right size, then they are probably too big (the sliders don’t change the physical size, only how large it displays, so you can have a billboard sized graphic that displays as large as a postage stamp).

I second Ioa’s recommendation about images.

Also, if those images are in the Draft folder and you’re trying to create a Scrivenings session that loads them all at once, you’re undermining Scrivener’s best tool for handling large projects. Scrivener only loads the documents that you’re actively working on, so best practice is to only load smaller pieces.


Thanks you two. I did reduce the size a lot yesterday by linking most images I have. However, I also inserted PDFs from musical score examples I need (musicological work), and there are many. I thought Scrivener allows me to store all that stuff inside the project, but by deleting everything from the research folder the project obviously shrunk considerably in size. I guess that’s the way to go for academic work…

But there’s still a problem: Compiling my work. Scrivener stops reacting and I have to force close it. I have reduced the size of the project to 78.6 MB by removing all images and scores and still can’t compile my thesis.

It’s due after Christmas so I don’t have for ever to get it done… Panicking slightly :open_mouth:

To clarify, the above has very little to do with the stuff you put into your binder as files, whether they be in the Research folder or your own custom top level folders. As a program designed for large-scale research, it will only load the items you request to see, and it will periodically flush things from memory that you haven’t looked at in a while. So it all should be very efficient for that kind of usage. Sorry for the confusion.

Perhaps I misunderstood what you meant by the “file” being 540mb. If you meant the project (which is potentially thousands of files) is that large, then that is like I say, really of no bearing to compile unless all of that bulk is attached to files in the Draft folder. I took it mean that when you compile an RTF file for whatever, it’s +550mb, which would be way out of ordinary for most things, and will cripple most word processors.

Compile halting at 70mb is probably not a memory or scale problem. That’s still a pretty large document, but well within what Scrivener can handle (in fact, in theory it should be able to export a 550mb RTF file, regardless of the utility of such a beast). It’s probably more a matter of a broken image file somewhere. These things can be easy to track down by compiling in halves, focussing on the half that halts, and continuing to halve that down until you’ve narrowed it down to the problem file, which should halt the compiler all by itself.

Best way to do that is:

  1. Select the first half of your Draft folder in the Binder.
  2. Open Compile, and in the Contents tab on the right side of the overview screen, set Compile: Current Selection, at top. Tick the Include subdocuments flag.
  3. Since we’ll be expecting this to halt, save your compile settings first by holding down the Option key and clicking the Save button in the bottom right.

Oh, and definitely do try RTF if you aren’t already. You don’t need DOCX conversion if you’re going to Word or any decent word processor. RTF is Scrivener’s native format, so it will all go much faster for you, as .docx conversion requires first compiling to RTF, and then booting up a huge Java executable and crunching through that very slowly. Word’s conversion will be faster and of higher quality.

Thanks @AmberV, I’ll give this a try.
Sorry for the confusion, I do mean the project :slight_smile:

I checked and found 3 very large images which I have now reduced in size. I’ve also replaced each and every image by inserting “image linked to file”. But even if I compile a version without any images it takes several minutes. So my guess now too was a broken image file somewhere. So I will try your trick with compiling in halves.

Do I understand right that LibreOffice can use RTF? (I’ll have to go to LO to convert citations in the footnotes).

Linking images to files (or binder items) is almost always going to be the best approach if you don’t mind the extra complexity. The alternative is stashing all of those bytes into the text files themselves, and that is what can cause lag, particularly in conjunction with the auto-save feature.

Yeah, LibreOffice handles RTF just fine. Is it taking several minutes for RTF, or is that with the ODT conversion? You can tell which process is going slow by what the progress bar looks like in the compiler. So long as you have a normal bar creeping up, that’s Scrivener creating the RTF file. Once it switches to a vague “stuff is happening” indicator with no progress, then the compiler is done and has passed the job on to the Java converter. At that point you should also see an additional icon in your Dock, while that is running.

Glad to hear you’ve at least got it functional at this point. Holiday deadlines are the worst. :slight_smile: