026 - Is there a memory leak??

After several hours of flogging the program, writing, saving, cutting, pasting, moving big blocks of code from place to place, etc (Roughly 50,000 words in current project), Scrivener begins to slow. I get windows messages that Scrivener is not responding, and indeed, the cursor won’t move, yada yada. Sludge.

I have been fortunate so far in that it has not crashed, just turned to oatmeal. If I’m patient, I’m able to do a final save, and exit the program. After a reboot, everything is back up to warp (??) speed.

I have an ancient Pentium 4, 1.5G RDRAM @ 400 MHz with i850 chipset running XP SP3, with the most recent updates.


Thanks for the report, Doug. Lee’s done some work optimizing the code, but he should soon have a chance to focus on these performances issues more. In another post he put up a list for reporting performances issue, which I’m just going to reiterate here, cutting the ones you’ve already explicitly answered:

  1. State exactly what you were doing when the performance issue occurred.
  2. Approximately how many documents, folders, and words does your entire project contain? If you’re working in a single editor at the time, please provide a word count for the specific editor document as well.
  3. When did you last re-boot Scrivener (i.e. full close and open)? – you did answer this, but I just want to be clear, you’d had it open several hours of actual work? did the computer sleep at any point during this?
  4. OPTIONAL: Anything else that might give us clues i.e. for the technically minded Windows Task Manager Performance specs/spikes when performing specific tasks in Scrivener. Also, any details regarding any auto-correction, substitution features you may have enabled or analysis of those features turned on and then off and the resultant performance change if any.

Any extra details you can provide here will be great. I know you’ve just been putting the program through its paces and it sounds like the slowdown was building up and happening in numerous places, but if there are specific things you know that cause it to go unresponsive, that would be great to know. One I’m aware of is attempting to view a group of lengthy documents together as a Scrivenings session–in rare cases, that one can be bad enough to end up with Windows force closing the program. But if you’re seeing a heavy slowdown for a lot of other actions as well, please let me know. At any rate, given that closing and reopening fixed everything, it does sound like a memory leak, so it’s probably a separate (or slightly separate) issue from the Scrivenings problem.

I’ll be more attentive today.

BUT, I abandoned Scrivener 026 the first time I tried it for the following reason:

  1. I imported a 46,000 word RTF file called TestMSS into Scriviner. That took a long time. Much longer than opening the rtf file in open office, or Word, or yWriter5.
  2. I then created 20 or so empty text documents with Ctrl+N and renamed them from untitled.
  3. Then I clicked back on TestMSS. Nothing happened for a long time except that the windows bar at the top of scrivener said “(Not Responding)”, and the Task Manager indicated 80-99% CPU usage. Eventually the document reappeared in the editor window.
  4. I opened one of the new text documents in a second window, cut the first chapter from TestMSS using Ctrl+X and waited a long time while 80-95% CPU was occupied.
  5. pasted it into the second window - no problem
  6. I repeated the process two more times.
    I moved a total of 4,000 words, less than 10% of the test manuscript and it occupied more than 6:00 minutes of CPU time. At this rate, I figured I might as well use a pencil or typewriter and just uninstalled Scrivener from my computer.

I decided to try Scrivener again, but what I did this time was cut my mss into 45 rtf files by importing into yWriter5 (it recognizes chapter and scene breaks on import) then imported those into Scrivener.


Hi Doug,

Thanks for the details. In future, if you’re giving Scrivener another go, instead of creating all the empty files and then cutting and pasting from the original import, you’ll want to use the “Split” command for this. Just start in the imported document, find where you want to cut off each segment and place the cursor there, then use Documents>Split>at Selection (Ctrl+K) to divide the document. The section below your cursor will be broken off into a new document, and you’ll automatically be placed in that new document so you can continue working your way down and splitting off each section. If you’ve already set chapter titles and such in the original document, you may want to use Documents>Split>with Selection as Title (Ctrl+Shift+K) to automatically name even segment as you go. Both the split commands are also available via the context menu in the editor if that’s easier. If you split a couple documents and decide you didn’t really want to split there, just select both of them again in the binder and then choose Documents>Merge to put them back together.

Hi Jennifer - Just tried that. It took 52 CPU seconds to import my 45,000 word test file.
took another 45 CPU seconds to perform the first split. 50 CPU seconds to perform the second. I clicked on the “wrong” file in the binder and had to wait another 50 CPU seconds while it opened that file, etc. It has taken over 7:00 CPU minutes to split off four pieces, each roughly 1000 words, from the original test manuscript.

So the fundamental problem is still there. Right now, Scrivener is really slow to open, or even re-open, a 40,000 word rtf file. Seems like a key performance problem to tackle. For comparison, FocusWriter required 12 CPU seconds to load the test mss, and OpenOffice required 5 CPU seconds.