Hi, not sure if this is really a bug or not…
Within Activity Monitor, my Scrivener NoMo 2.0 instance usually sits at 80MB on startup and creeps up from there to (at least) 150MB. Virtual is usually <80MB (I think)
But I’ve just run a project search and replace and it took several minutes to run through the 357 files (About 162k words). While it was doing this it maxed out the CPU and memory usage peaked at over 700MB (Real) and 500MB (Virtual).
After a few minutes later and the Real Mem usage dropped to just under 400MB, but virtual didn’t really change.
My MBP only has 2MB of RAM (I know - but my uber rig is my PC, I may hack hackintosh it one day) so an app which grabs a lot of RAM like this had a real big impact on the rest of the machine.
After I restarted Scrivener, I got back to the normal levels of RAM usage.
If I’d have left things alone would the memory have been collected again by the OS? I believe in OSX garbage collection is automatic (unlike iOS) so maybe this isn’t a memory leak.
But just wanted you to hear my report in case it was.
Automatic garbage collection is a bit spotty, actually. You are right that at the OS level, it will usually do a very good job of managing memory and reclamation. I’ve noticed Snow Leopard seems to be a little less reliable at this than earlier versions over long periods of time. The system just gets a bit slow after a week or two of just using sleep. Sometimes logging out and back in is good enough, but a full reboot is often necessary. This seems to happen most often with programs that take up huge chunks of space like Photoshop and Parallels.
Garbage collection at the Cocoa level is a relatively new feature, and Scrivener doesn’t use it. Otherwise it would have to drop Tiger support entirely, as that OS doesn’t support it, and switching from manual to auto is a fairly major project—one that has its pros and cons for that matter.
Anyway, I don’t think this will solve the leak unless I missed a change note (entirely possible as I skimmed bug fixes), but you should upgrade to the latest version if possible. The NaNo version was an early preview and a lot of bugs have been fixed with it—not to mention final polish added.
Sorry, although I never got around to replying to this for some reason (probably because it was posted while I was in the midst of the mad panic of trying to get 2.0 out), I did add the details to my list of things to investigate. I added an autorelease pool to the project replace loop which should free up memory as it cycles through, so that it never eats up too much. So this should be better since 2.0.1. Let me know if you still see massive memory usage though.