Why is Scrivener so slow?

I’ve seen a lot of features and fixes that are being looked at in the beta, but I haven’t seen much on performance issues. In my experience, any time I click on just about anything in the binder, I can expect to wait 30 seconds to a minute before it responds. The higher the object in the tree, the worse delays I see when clicking on it. Now I have a pretty good sized project, but not more than a dozen or so documents in the research folder (with no media or other unusual files in any of it).

My computer is not super fast I’ll grant, but right now Word 2007 runs circles around Scrivener in the speed department. Typing in the actual editor seems fine, it’s just anything in the binder or tools such as the name generator. I’d just like to know are there known issues here that we can expect to be addressed in the final release? Is it just me seeing these slowdowns?

I have the same issues with performance when editing large documents. If I open a 300K+ word document, it barely keeps up. I also inquired if this would be fixed with no comment.

I hope the final release will address large manuscripts manipulation timing issues, otherwise I will have to move over to word to finish my creation that I started in Scrivener. I suspect it is a memory handling issue but I am not a programmer.

Hmm. I just made a 100,000 word/600,000 character text to put in a single binder item, from a long enough PDF lying around.

  • in Scrivener, pasting in takes 5 seconds, and scrolling around is instantaneous. Clicking from another normally short binder item to this one takes about 1 second, maybe a little plus.

  • in Word 2003, which is generally very snappy indeed, and using its fastest display mode, Normal, which is comparable to Scrivener, pasting in takes 10 seconds - twice as long. Scrolling is also instant, but only after Word gets through paging the document, which is endless and silent – during that period of minutes, scrolling is a 10-20 second thing. Switching between two copies of the document is instant, as is working with splits.

  • so this got me to try making a second binder item of the same big size, back in Scrivener. Now only do I see an appreciable slowdown, switching between two 600Kchar articles. On the order of 20 seconds, so maybe what you see. Yet this happens, I found, only on the first switch of binder items. After that, switching even between two 600Kchar giants is only a second or so.

  • I got similar results making a third huge binder item. Same time to paste, longer for the first switch - to each of the other huge items. After both others had been switched to, Scrivener was again taking a second or two to switch between them.

But again, I’m doing something which seems pretty unusual, having these binder items which are each mammoth in themselves.

Also for reference, I am doing the Scrivener tests in a document that has on the order of 100 ordinary-size (page or so) binder items, and a few more in folders within it. Machine here is dual-core 2GHz 3GB laptop, reasonably fast hard disk, lean on CPU onboard cache and in-memory graphics ‘card’, as it’s a fortunately priced Lenovo model. I would say pretty normal recent laptop.

My conclusion is that anything like normal use of Scrivener would not be slow here, indeed faster than Word.

Also, the behaviour of slow-once, but fast-for-item-hugeness-ever-after seems to say Scrivener is being pretty smart about doing a once-only internal organization for document structure and memory use. And it is doing it a lot faster than Word does – remember the minutes-long paging setup interval for Word before it attains useful speed.

That’s here, though. Whatever is slowing you guys down, it doesn’t look like it would be straight memory usage either, unless you are really short, as Scrivener is taking only about 50MB with this size document, and 64MB in the case of three huge items.

Do you see heavy disk activity during the slowdowns, which might indicate your Windows is memory swapping? I see no disk activity for Word or Scrivener here.

Hoping this will help getting on a trail, and build some confidence that Scrivener seems pretty solid at least as things operate here. I’m using the recent 1.6, and believe I remember doing a clean deinstall/install manually, not that I think that matters any more.


What are your system specs? (CPU, RAM, etc)

I created a 100,000 word document (lorem ipsem). Any time I switch to viewing the entire thing (binder, scrivening mode) there’s a second or two before it displays, but nowhere near 30 seconds to a minute.

Memory usage is staying constant, and negligible, compared to something like firefox. (I’m sitting here, watching it on top, and it’s not changing at all.)

Also are you sure it’s not a problem with your computer? If windows partitions aren’t defragged regularly, they will bog down and slow down.

Another thing to consider (sorry if this was mentioned above) is where the project is saved. If you have it saved on a flash drive, this can slow things down considerably as most of them are slower than hard drives when reading, and much slower when writing. Scrivener is a very I/O intensive program; that means it does a lot of reading and writing. Just clicking around and reading things will cause it to read and write from the disk (that’s how it saves what you were looking at last, and how tall the top split is, and so on).

If it is on the internal drive, the fragmentation lead is a good place to check. Larger files can get scattered all over your hard drive, and this means the drive has to “seek” multiple times to read the whole file in. This can cause even a high-performance drive to exhibit slow behaviour due to the physics of moving the drive head around.

It’s definitely not any kind of disk issue. There is no disk activity at all during the pauses. It also isn’t related to the size of the text files, but seems to be more the number of files. I think the issue may be related to the binder with multiple sub files–especially the cork board. Again, typing speed is not an issue. My project is broken out as follows:

1 Project folder
8 sub grouping folders
65 chapter folders
1-3 text documents per folder that average 3000-5000 words.
total workd count is about 260k

Everything is saved to the local hard drive with has plenty of space and again, there is no disk activity during the pauses (only the spinning curser) so it isn’t a storage/memory issue. CPU is 1.6ghz single core and memory is 1.5GB. Nothing super, but again, runs Word fine, so I would expect Scrivener to do even better.


Except I wouldn’t imagine that you ask Word to open 100+ files at once… Remember that each element within a Scrivener project is its own file, with its own set of metadata. In the corkboard view, if you change where you are in the hierarchy, Scrivener has to load all the metadata for however many files are at the new level.


When I click on an item in the heirarchy, it only has to open the objects at that level and that objects immediate children and not anything below that. This is usually anywhere from 6-12 “cards” that appear in the corkboard and not 100’s of files. Again, it isn’t a loading files issue as there is absolutely no disk activity at all when the issue is occuring. It’s obviously chugging away on something, just not something it’s trying to get off the disk.

I decided to do some real digging and found some interesting information that hopefully will shed some light on this. I used some process monitoring tools and discovered the following:

Immediately proceeding the ‘hang’:
The previously edited file was closed succesfully with no delay.

During the hang:

  1. Scrivener.exe is spiking the processor.
  2. Scriverer.exe is not accesing any files whatsoever.

Post hang:
1)The first file activity is the registry keys for the autospell. Specifically: HKCU\Software\Creative HQ\Scrivener\Options\Autocorrection

This is consistent and I can repeat this behavior over and over. I think what may be happening is the autocorrection thread is going into limbo for 25-40 seconds. Perhaps on newer, multi-core machines, Scrivener doesn’t hang because there’s more than one core to handle non-hung threads. After it then whips through the autocorrection keys, the text editing options follow next. From there, it accesses whatever object was clicked on and buzzes through everything normally until it is repeated by accessing something in the binder. The delay doesn’t happen every single time, but is often.

I was also able to track a second hang that was a little different. This time it spent 10 whole seconds cycling through the auto-correct registry keys while the interface was hung. It then went on to open every single child object. From what I’ve found, it appears that the root cause of the slowness I’m seeing may be something with the auto-correction/spelling function.

Hope this helps clarify things.


I have the same issue, always with projects with a certain number of files.

A project with 5 of 6 very long files inside will open very quickly.

Another one, half as big, but with many smaller files and metadata will open and react very slowly.

This is with Win7, a dual core processor, and with all the files on local HD.

I’m quite sure that’s it…

But even then, Scrivener is the greatest thing I have ever been using for my texts…

danwdoo, I think you’re definitely on to something there.

I turned off everything I could about autocorrect, and now each of the times are much improved even for the multiple gargantuan binder elements test I ran above.

This may make it much easier for Lee to track down and deal one way or another with the issue.

I am still smiling that Scrivener is so much faster than Word on usefully opening long files, apparently since it doesn’t run a large ‘paging’ operation on them.

Which honestly, though, Word has to, because it reports immediately about page boundaries, rather than wait for a compile step as Scrivener. Just different operations to serve different needs.


Okay, great info here. We will take a good look at this before the final release. Thank you.

Great, Lee. One more tidbit is that apparently having big things in the trash can cause a bit of slowdown, though not severe.

I had the three huge (big, big1, etc.) fragments from testing in my trash, having not thought about it. When I did think and emptied trash, Scrivener was quicker to open the project. No big delays like the once-only switch-between-huge-fragments reported above, but every little bit helps. I don’t know if you can do anything, except possibly not read into memory what’s in trash unless a fragment is clicked on in the binder - taking the smaller hit then.

Regards, and back to my nitting,

I’m definitely noticing that it’s slower and using more resources than earlier releases were. I’m seeing the cpu occasionally pegged, and memory usage spiking up to 80% or so, with only Firefox and Scrivener running. Granted, this is only a little netbook and not a high-powered machine, but I was getting much better response time a few months ago.

Most of the time, it’s only using about 55MB of memory to run, but sometimes, for reason(s) unknown to me, it’s up around 230MB. What I’m doing at that point is opening a project, switching between corkboard and Scrivenings views, and checking out the zoom options.

The file I’m using is about 50k words, split into 33 (um, vocabulary fails me here) text files? I have very few supplementary files, and according to Windows 7, the project folder is 1.15Mb, and contains 132 files in total. It’s on my hard drive.

Since it worked great before, the comparisons to Word are probably not really relevant at this point. Software design (which has been my career for nearly 30 years) is a series of tradeoffs, and if “opening many files” slows down the product to the point where it becomes problematic, one would question the design. However, that doesn’t appear to be the case, since it seemed to have handled that quite gracefully before, and I have every confidence that it will again. This was a BIG update, and Lee said there might be new bugs, and we’ve seen that he’s a world-class bug-squasher. :mrgreen:

LaughSing, the reason to have compared to Word was to have an initial benchmark, to which Scrivener compares favorably. Word’s had its years of development, and was done within the mother ship itself.

Anyway, let’s see how things go for Lee – not much use in speculating, as performance things tend to be measured to have their bottlenecks where you might not have expected them, or would already be designed out.


I’m experiencing slow behavior with 1.7 that I didn’t see in 1.6 (my first beta version). I’ve got a project (started from blank) that has ~10 texts in it. Most of those are empty and/or short. One text, however, has a paltry 3000 words and is SLOW as a dog to work with having gotten the new beta this weekend. Cutting, copying, pasting lag but (worst!) the cursor has noticeable lag changing line positions (some times 3 seconds) and typing is regularly slow to appear. Once I start typing in a new cursor location and it gets caught up with me it usually hangs in there pretty tight but if I change cursor locations, woe is me. The other texts in the project behave perfectly fine; one of those, for example has 600 words another has 1700. If I find a tipping point from OK to lagging, I’ll report back.

Thank you for your work on this AWESOME project.


Windows 7 Pro x64, Lenovo ThinkPad T400 w/ Core2Duo P8600@2.4Ghz, 4GB RAM