Since I started using Scriv 2.02, it has been agonizingly slow – so much so that I began using MWord for new projects.
The main, but not only, culprit seems to be the backup function, which has taken as long as five minutes at shutdown and has never taken less than two minutes. For instance: I just shut down my computer, turned it back on, opened a Scriv, and performed a manual backup – and it took 2 full minutes despite my not having done any new work.
I have already unchecked the “compress automatic backups as zip files” box.
Backup is not the only time Scriv has slowed to a crawl – often when I come back to it from another program I get a spinning wheel, and doing something as simple as using the search bar can result in multiple waits as the application seems to work and then temporarily freezes.
At the moment I’m working with a large file - about 500mb – but it has happened with files as small as 80mb. I never had this problem with Scriv 1.x.
This is horribly, incredibly frustrating. Is there some way I can switch back to whatever the last version of v 1.x was?
(And: don’t even get me started about what felt to me like an underhanded way to force people to pay for the upgrade. There was an acknowledgment when brought to the pay page that people might not have realized they were downloading a paid upgrade – but no way to decline at that point and revert back to the previous version. As a self-employed writer, that was really frustrating. I’m sure I would have paid the $25 – but I would have liked it to have been by my own choice. OK - sidebar rant over.)
Automatic backups, by default, run whenever you close the project no matter what you do in it, and they create a complete self-contained copy of the entire project each time, so it doesn’t matter if you just change one letter, it still backs the whole thing up. This is all by design, and in most cases it happens in under a few seconds; otherwise it probably wouldn’t be a default.
For large projects, use the [b]File/Back Up/Exclude from Automatic Backups[/b] option. If the whole thing is just too slow on your computer, you could just disable the whole feature in your Backup preferences pane and maintain your backups by hand the old-fashioned way.
What sort of system are you running on, incidentally? I have another case that sounds very similar to yours, especially in regards to project search being extremely slow to the point of uselessness. This person is using a very old G4 computer, but 1.54 had no issues. We are investigating the cause of the slowdown. On most machines there is no difference in search speeds between versions, and in fact in some cases things should speed up quite a bit, especially in the realm of typing. So what you are experiencing is definitely abnormal and I’d love to get to the bottom of it.
The old version can be downloaded from our support page. Regarding “forcing” you to update, I have no idea what you mean by that. The entire thing was optional from top to bottom and what was happening was communicated at every step. The preferences for version 1x are separate from 2x, so when you re-install the old version, you’ll find everything as you left it—in fact it’s fine to have both installed at once, by design.
If you’ve upgraded projects and done a lot of work in them you’ll need to export that material using [b]File/Export/Files..[/b] or compile, first. Your 1.54 projects were backed up when you upgraded them, and you’ll find them right next to the new copies in the Finder, with the name “Backup” in them.
There were large, bold, red letters in the automatic update box announcing that this was a paid update and capital letters saying not to download if you didn’t want to pay - of course we can’t force users to read things, but it’s unfair to complain that we were underhand just because you didn’t read the big red print. Moreover, when Scrivener updates a project, it creates a backup in the old format, and as Ioa ha pointed out, 1.54 is still available from our website, so you could easily have returned to it without paying (all of that was explained in the notice that you ignored when you clicked “Install Update”, too, but you could have just e-mailed us and we would have explained all of this and helped you return to 1.54). We didn’t force anyone to update at all (although updating to 2.0 is certainly recommended as I worked solidly on it for two years and it is much improved over 1.x).
Hopefully Ioa’s help with the backups will do the trick - a 500MB project would take a while to backup. If you still experience slowdown after that, let us know and we can take it from there.
Inre: “forcing”: I should have chosen my words more carefully. I apologize.
I’d venture to guess that most people instinctively click the OK box when presented with a pop-up alerting that a new version of a given program is available – and I assume that many people did not realize this was a paid upgrade. It seems that the folks at L&L assumed that as well, because of the message that appeared subsequently to the effect of, “We know you may have clicked through and not realized this was a paid upgrade.” I didn’t see anything on that page letting me know that if I did not want to go through with the paid upgrade, I could take the following steps: Go to the “Download” page on the L&L site; locate v 1.5; download; reinstall. Since my workflow had already been interrupted, I didn’t then go and Google how to revert to a previous form of Scrivener.
Obviously, I wasn’t forced in a gun-to-my-head way, or even in a this-software-will-no-longer-work-if-you-don’t-upgrade way. “Underhanded” might also have been too strong a word; I did feel that the upgrade process was less transparent than it could/should have been. That, combined with a severe drop in performance, was (and is) frustrating – all the more so coming from a company that provides an excellent user experience and excellent customer support.
I use Scrivener – and I love Scrivener – because it makes my life much easier. That makes it all the more noticeable when the opposite is the case.
Now, on to the real issue at hand…
I have a 2GHz MacBook with a Core 2 Duo processor, upgraded to 4GB (from 2GB) of RAM. It’s about 18 months old. I use it to run graphics programs, audio coding programs, etc. It’s certainly not on the level of the new MB Pros, but it should be fine for this.
Not sure I understand this. I haven’t done any significant work in my projects since the upgrade. After the upgrade and the slowdown, when I was able to establish that “MS backup.scriv” contained the same data as “MS.scriv,” I trashed the “MS backup.scriv” doc. Is there something I should have have that backup file? If I can locate the most recent 1.54 version of MS.scriv, is there something I should do inre: exporting with that?
The backup-files were the files in the Scrivener 1.x-format. The new ones, created with Scrivener 2.0, have a different file format – and there is no way back.
Strange. This happens several times a year for me with all of the programs I have installed. I always read the first two lines to make sure the upgrade is free. If it isn’t, and I’m not interested in upgrading at the time, I click “Skip this Upgrade” and it’s done. This isn’t exactly uncommon in the Mac community, and most aren’t as obvious as we were about it—and not everyone provides easy to discover links to the older version on their website. Now, maybe you aren’t exposed to that, so this is mostly just a culture shock type thing for you. No harm in that.
Okay, your equipment is not even remotely in the same realm of oldness as this other machine, which was a G4 with a processor clock speed in the triple digits.
That’s actually a good result in my mind—because it means there is some bug or interaction with third party software going on here, and not just a blanket, “Your computer is too old for Scrivener 2” issue.
Um, yeah, you really shouldn’t have deleted your backups. I hope you have Time Machine or that they are still in the Trash, or something. I’d say “You were warned in the message when you upgraded the project…” but.
OK – but I’m still not sure what means functionally. What would going back to 1.x have done? Would that only have helped if I then went back to using 1.x, or is there something I could have/should have done with that to make things run smoother in 2? If that’s the case, I think I can re-create what I’ve done since I made my last Time Machine backup in 1.x.
agreed. it’s gotten a little better since i stopped the auto backups. i’ll keep on tinkering.
It only matters as far as returning to 1.x, should you have decided to do that rather than continue with 2.0. 1.x won’t open projects that were created in/updated to 2.0, so you’d need a version still in the 1.x format. Scrivener 2 thus creates a backup automatically when updating a project, but if you have your own still stored elsewhere, you’re fine. Unless something really weird happened, this is all unrelated to whatever’s causing 2.0’s slowness on your machine.
This question is relevant only in trying to figure out what the cause of the slowdown is: Is the backup feature new to 2? And what are the advantages of this v. just using Dropbox for backups? I just tried it out and was able to download the latest MS.scriv file from my Dropbox and it opened in Scrivener successfully…
I’ve gotten things a little better by shutting off automatic backups (and not usually the backup function at all but relying on Dropbox instead)…but it’s still noticeably slower than it had been. Opening a project takes about 10 seconds. Closing a project – or, rather, closing this fairly sizable project – takes between 15-20 seconds to cycle through “saving search indexes” and “saving quicklook previews” – and this is without making a single change to the document itself. That’s not rip-your-hair-out time, but it’s 3x to 4x slower than it had been previously. I haven’t tested how long it takes to close after spending a couple of hours working on the project.
To chase down the slowness issue, it seems like it would be helpful to know:
i) do the projects in question reside on your hard drive, a USB flash drive, a remote disk (like an iDisk) or what?
ii) are you running any always-on, utilities or helper applications? Knowing what these are might help bring to light a potential conflict between apps.
iii) what is the size of the project files in question? (are they huge?)
Sure - a bunch at any given moment. Quicksilver and Pathfinder almost all the time, but those take very little CPU or MEM when not being actively used. And again, none of this is any different from when I’d use 1.x – I’m not suddenly running lots more problems.
It’s big - about 500mb - but again, it hasn’t grown any since I transitioned from 1 to 2.
Would it be possible to provide a screencast of the slow search result, or attach a complement of an exported preference file, a layout file with full settings saved into it, and optionally a sample project? The one other case that I know of with this produced some diagnostic files which indicated excessive drawing routines were being invoked during the search, in one of the search result cells. If you want to provide some diagnostics as well, use Applications/Utilities/Activity Monitor. Click on Scrivener in the list (you can filter in the toolbar if it isn’t visible) of processes, Cmd-Tab back to Scrivener, start searching, and quickly jump back to Activity Monitor and hit the “Sample Process” button. Once that is complete, use the “Save…” button to save as a file and attach it as well.
If you’d rather provide all of this via e-mail rather than using the public forum, they can be sent to support AT literatureandlatte DOT com. I’m mainly curious to see whether or not these issues are the same thing, despite the massive difference in hardware capability, or if they are in fact two different things.
I just noticed a performance drop of 2.x as well compared to 1.x and I think was able to pinpoint the reason (in my case at least). Searched the forums and thought to post here even if i’m not sure it’s the same problem. I only noticed as I switched to working on a new mbair, on 2010 mbpro the issue does not occur (okay, maybe that’s clear).
when putting more than 2 screenshots (just to say no 300dpi 5mb-thingies) in any given chapter as document notes, it becomes unusable (spinning wheel/input delay >2sec nearly every time you jump within text). And I am pretty sure that 1.x did not have that issue as i used that one fairly long with a 2004 powerbook way slower than the air and the old project was heavier (overall and in terms of pics/chapter).
i really hope it’s a bug or you can tell me something to turn off to make it work. for me, working in full screen with pictures matching what you write about is one of the most awesome features of scrivener.
kind regards and as always: Thank you for programming my writing home! (Keith, you are actually mentioned in the thank you section of my first published book if my editor does not take that section out (she won’t) - will send you a copy once it’s out - august. takes forever). The Thank you will be in English - the book unfortunately not.
Thanks for posting that, as I was about to the do the same. Just the other day this issue came to light and I meant to update this thread. If you use a lot of graphics in your manuscript, 2.0 will very likely bog down. The reason is: behind the scenes things have switched to platform-standard RTF, rather than Apple’s RTFD format that nobody else can use. RTFs must embed the images directly into the text itself, which will slow down everything since auto-save is now firing off big chunks of file instead of neat tidy text files.
There is a solution: Linking. Use Edit/Insert/Image Linked to a File... instead of just dragging it in. This keeps the file outside of the RTF entirely, but you will still be able to view it in Scrivener as though it were there. Other advantages mean you can more easily edit these files and swap out updated revisions from the artist, or whatever the case may be.
Thanks AmberV. For me that solves the issue entirely - at least hopefully. Two Questions on that:
will scivener backup those files in the .zip’s? (my guess: no)
if not: what happens if i loose pictures? will scrivener just work fine or will it crash? I wouldn’t mind (too much) manually backing up pictures and links - but only if they don’t cause unstabilities if they get lost.
if the answers are no and no, I’d like to post this as a feature request for a “backup package” option.
I know how much you must like feature requests … sorry for that. but maybe its “yes, yes”?
No: just as with items dragged into the References panes, they are not physically a part of the project. This has advantages and disadvantages. One of the advantages is that you aren’t burdening the project file with lots of media. This keeps backups tidy and quick. Changing it so they are zipped in the backups would defeat this advantage. You just have to modify the way you work a bit; and this isn’t an unusual way of working—especially for those who have ever used InDesign or Quark. Keeping assets with the master files is a part of the job.
If the original pictures are not present for any reason, they will come up with a generic file icon in the document. The original reference is preserved, and will patiently wait for the original files to be replaced. This is key: this means you can take the .scriv file with you on your laptop and forget your image folder (or leave it behind intentionally for expediency). When you return to the desktop; all links will be preserved.
[quote=“AmberV”]
If you use a lot of graphics in your manuscript, 2.0 will very likely bog down. The reason is: behind the scenes things have switched to platform-standard RTF, rather than Apple’s RTFD format that nobody else can use. RTFs must embed the images directly into the text itself, which will slow down everything since auto-save is now firing off big chunks of file instead of neat tidy text files.
Actually I don’t think this is quite right. There should be no difference between 1.x and 2.0 in this regard - the switch from RTFD to RTF should make no difference. Even in 1.x, when files were saved, the entire RTFD file was re-saved to disk, so files with lots of graphics should have had the same slow saving as in 2.x. It is possible that the standard Apple RTFD saving methods were optimised in some way to avoid re-writing the images each time, but I didn’t think they were. I’ll have to look into it to give a definitive answer there.
@AmberV: I use .indd on a daily basis and believe me, without the “save package” option, this would be tough to manage, but anyway: good news, that srcrivener will deal with missing files like that, so there can be no catastrophies.
@KB: I guess it cannot only be related to the “save” issue. If I put pictures in: wheel or delayed text, even with regular (fast) typing and no 2sec pause. Remove Pictures: issue gone. Just as background information for you: project is not that big (46 mb). pictures causing this are 900kb / pic. Old project that I used with really slower machines and 1.x without any problems had 138 mb and tons of pictures and .pdf’s in some chapters. never had that issue in 1.x. I’ll be glad to test if the issue also affects more powerful machines once i get my mbp back (logic board crashed -> nice reason the get the air having to deliver the new novel by end of dec).
