Lovely tool. Used it to add 20K to a novel, now being touted by agent.
However, file handling seems slow. Takes ages to load. Then, switching to the entire novel selected in scrivenings takes a couple of seconds. Find/Replace (which could do with enhancing, btw) causes the screen to freeze like it was 1998.
I’ve got plenty of memory and it’s the only ap I’m using. Couldn’t you have some cunning preload option? Scrivener is welcome to hog my PC’s resources.
(3GHz, 2 GB RAM, lots of harddrive.)
Hi Zornhau, this is always a tricky subject. I have only written a few large tech manuals over the years using Word and it was notoriously slow when I had all of my images and 80k words in it. I really like Scrivener because each chapter so to speak is a different file which makes things move along quickly for me.
Also, RAM is always an issue. I have 6GB RAM on my computer and Windows only reports 2GB of that is available. The only program I have open right now is IE9.
Anyway, I don’t know any more specific details of your computer or novel so I can’t comment more than that. We’ll get it figured out if you can give us more details about them.
Thanks, Chris
They’re working on it, as I gather from other topics. What worries me more than the time lag, are the reported crashes with larger projects.
I don’t think RAM is the problem. Unless you juggle tons of media files in Scrivener, the size of your project is unlikely to amount to several hundreds MB. If Photoshop and Video editing run smoothly on a PC, why shouldn’t Scrivener?
I think it may be related to the tempfiles problem but they’re working on that, too.
I have other applications that also save out my stuff into seperate fragments, text files etc. My oldest project contains +5000 files, and is still lightning fast.
Let’s hope the next update will fix these slow-downs.
Chris,
the reason you only have 2GB available (which still should be plenty to cover your Scriv-files) is probably that most of your 6 GB is reserved for the system cache.
This is a good sign, not a bad one. The cached memory is reserved to hold your open files, for fast access. No matter how much RAM you install, most of it will always be put away to cache frequently used files. Again, this is desirable.
So, is this a good thing or a bad thing? As I understand it (and I’m not associated with L&L in any way), forming the scrivenings view opens every file in order to create the view. So I could understand why it takes a little while.
Then some folks might say “Well then, read only what is necessary in order to form the initial view and then form the rest as I come to it.” The issue I would worry about then is that until I visit the entire document, scrolling will suffer from at least a little lag while the next file or two or three are opened and added to the scrivening. I wonder if that would simply be the next “the darn thing is still slow” issue? It seems like a “pay me now or pay me later” kind of problem.
The quickest and, one might argue, the best fix for slow I/O might be to invest in an SSD drive.
I advise against your suggestion. It is an expensive remedy and not guaranteed to bring relief. Readout is fast, but not writing to the disk. Write-cycles are limited. You wouldn’t want to burn them up with Scriv’s way of autosaving and the thousands of files that accumulate in the temp folder.
Why should it bother your workflow if another core or processor thread is handling the I/O load simultaneously? We’re talking text here, right? Not editing movies or music projects. 100 MB of data, not 2 or 3 GBs. Even that is no problem. Audio-software streams in thousands of files unobtrusively in the background, while I am editing them in the same program. As long as it doesn’t stumble over its own autosave cycles, this is no problem at all.
Here is what Scriv’s programmer has to say about it:
Lots of small files tend to be a bigger resource hog than big media files. The file system is optimized for larger chunks of data to be read sequentially. A project with a lot of small files means that the system has to refer to the file allocation table, seek, and retrieve or write the data. It’s a lot slower.
You can see the same effect when extracting or compressing zip images with hundreds of files.
It might be faster to create two different formats at save time (a project with all the files and a monolithic blob for quickload on resume) but that’s a lot of work for a second or two of convenience.
I have 300,000 of small files in my Kontakt3 and Gigapiano folders. Every key is sampled in a zillion velocities and timbres. You hit a key on the piano and hear its sound, plus pedal, plus overtones (a few hundred for each keypress).
If the delay were more than 10 milliseconds you couldn’t play smoothly anymore. In real time I am editing these waves, applying reverb, and drum samples on top of it. No fan noise. I type for 5 minutes in Scriv, the fan kicks in.
Nevertheless, you are right, generally, if you meant “many small ones = same size as one big file”
But despite this, Photoshop for instance, only loads small bits of a picture, one by one, many of them. Still faster than dealing with the whole thing. It can be handled. And I am positive Lee will fix it.
You’re likely pulling those files in via read-only, and caching everything based on the instruments you’re using (not familiar with either tool) because the hard drive bus is a major choke point. When you can read the instruments into memory and utilize that bandwidth it makes sense, since you’re not writing out to all those itty bitty samples. That frees up your output to your own generated media. And slows you down less.
Oh yes, I am. They’re not smaller than text files, btw.
I didn’t mean to be a smart-ass. Just wanted to make clear that this is NOT about RAM or I/O or technical limits. It’s a Scrivener problem that the developer has acknowledged and that is being fixed.
Got a big SSD, fine for fast PC startup but it doesnt solve the “Slow” Scrivener problem
Now I’m curious. StefanG, could you point me at Lee’s comments on this bug?
I didn’t say it was a bug. I’d call it a kludge, because it is not a malfunction. Just a temporary “poor implementation”. But both expressions are not allowed on this forum. They trigger heavy attacks from other users. I have become wary of my wording here. So please don’t say I called it a bug. I did not.
I don’t remember from where I pulled the above quote by Lee. But I assure you it is real.
News about the lag issues:
https://forum.literatureandlatte.com/t/when-can-we-expect-scrivener-2-0-for-win/16832/1
(Just in case somebody has just tuned in and is dithering over getting Scrivener - even with the odd glitch, it’s still better for writing novels than Word or OO)
Found it: Won't Start
Hi all,
Apologies that you’ve been experiencing a lot of lag with the program. As mentioned up thread, Lee is working on various optimizations in the code which should help a lot with these problems. He’ll also be working over the next several months to rewrite a lot of the code for loading Scrivenings sessions, as the latest update to the framework Scrivener uses now allows for a much speedier rendering of the text, and this will help significantly with viewing a host of files as a Scrivenings session. Our goal is certainly that Scrivener be reliable and snappy working with large projects as well as smaller ones.
In the meantime, here are a few basic things to try which may increase the speed of working in your project. They may not all be relevant to you or possible with your work method, but if you can, give them a try:
First, working from a project stored on a networked or external drive, or even on a partition separate from where Scrivener is installed, can cause a bit of delay, especially on larger projects. If this applies to you, try moving the project (when it’s closed in Scrivener) to your local drive for working.
Second, you can go to Tools > Options… and click the “General” tab to try increasing the auto-save interval—by default autosave runs every two seconds of inactivity, but this might be just the right period for it to kick in just as you start typing after a moment’s pause. You can play with this a bit to see what helps—10 might be plenty. Just remember that this is seconds of inactivity, rather than every x seconds regardless, so if you bump it to 60 seconds, for instance, you’d need to not be working in the program for a full minute before Scrivener autosaved. If you do set a higher number, make sure that you’re keeping an eye on the asterisk in the header bar (indicating unsaved changes) and using Ctrl+S (File > Save) as necessary to keep your project saved regularly. (Autosave will always run when you close the project, regardless of the interval set here.)
Third, it may help to work in smaller sections at a time. Loading a large Scrivenings session or a lot of index cards on the corkboard can cause some slowdown right now, so if that’s something you’re seeing, you can reduce this a bit by further grouping your documents in the binder, so that selected containers have fewer documents in them, or by using Ctrl-Click in the binder to select fewer items to view at a time. This may not be possible depending on how you’re working, but if you can group the items in your Draft or Research into further subcategories (at least temporarily), that could help reduce the strain when Scrivener tries to load them all in a group view mode.
Finally, if you’re having problems with start up and your project is set to auto-load, you can turn this option off by going into Tools > Options… and deselecting “Open recent projects on program launch”; this will speed up Scrivener’s opening time, if it’s the strain of opening your project that’s slowing it. Opening the project will also take longer if you’ve left the editor displaying a lot of files in a group view, so trying to close with just a single text document open or the like will help speed up the load time when you come back.
As I said, these aren’t meant to be “the way it is” in Scrivener but temporary workarounds for the lag problem while Lee works to get that sorted out. Thanks for the praise of Scrivener even in the face of these setbacks and your support of the program helping get things shipshape!
Very good and valid points, Jennifer
Let me add a word of caution to owners of SSD-drives. Just to be on the safe side, you may want to move your %temp% and data folder to another, less expensive drive. Wear leveling (done by the SSD controller) had failed on my SSD and it was no longer functional after the same location had been overwritten many times. It was a an older model with few write cycles, though.
Take into account your autosave settings, and the number of files in your temp folder. Then run your own numbers. Depending on the model of your drive, its available free space and the type of wear leveling it entails, this may not applicable to you.
The new SSD drives are indeed much better than the older ones in that regard. Even with typical OS virtual memory usage, they should have a use life as long as an ordinary platter and head drive, and maybe even exceeding them in some cases (especially in laptops, where vibrations can reduce the lifespan of a mechanical drive considerably, but have no adverse affect on solid state). Both the chemistry and the logic which spreads usage around has been improved. But it is a good idea, if possible, to assign temporary, cache, and virtual memory to a cheaper drive if possible.
Amber,
do you happen to know if there are models where the drive does NOT have to go idle in order for its garbage cleaning mechanism to kick in? Someone told me so, but I am not sure if this is a myth or for real.