zeniko wrote:I recommend you...change that interval to something around 30 or even 60 seconds to alleviate the issue.
I did and it seemed to help.
The more interesting question here is whether it is possible to reduce the impact of that save operation. It's too bad there aren't facilities in JavaScript to run code at a lower priority. But it may be possible to split up the task so the interruption is less noticeable. For example, saving 1/3 of the open tabs every period/3, or something. (If the biggest CPU hit is from writing crashrecovery.dat to disk, then doing the above might just make the problem 3 times worse.)
zeniko wrote:Yes, Session Manager has to parse the session files in order to extract the sessions' names...
And does 15 to 20 seconds seem like a reasonable time to scan 20 session files? (Not a fair comparison, but 'grep -e "^name="' runs in under a second.)
How about the delay in showing the options dialog? Unlike rendering the menu, whatever it is doing isn't cached, so the delay occurs every time, and uses up 100% of the CPU for the duration.
(Though neither of these affect normal browser usability, so not really worth much optimization effort.)
zeniko wrote:tmetro wrote:(Does Session Manager hook into that event?)
It does so as well, but the impact should be minimal.
The impact from most of the things we are discussing should be and are minimal under normal circumstances. (The exception being saving sessions, as discussed above, which is not quite minimal, even under normal circumstances.) The problem is that once this threshold has been crossed in FF, it seems particularly sensitive to anything that runs JS code.
zeniko wrote:You might want to try to reduce the number of reopenable closed tabs to 3 (or even 0) to get more free memory...
OK, that's doable. When I initially installed Session Manager I had boosted both the number of tabs and windows to remember up to 10. I switched them back to 3 (which I think were the initial defaults).
I also had "List all closed windows and tabs in a submenu" checked, and so I unchecked it. It isn't clear whether this option is describing how the information is presented ("in a submenu" as opposed to what?) or if it is overriding the numbers entered above ("List *all* closed windows and tabs..."). If the latter, checking it should disable the text boxes. (Is there a Session Manager wiki?)
What kind of data structure is used to store the information that is only being kept in memory because of Session Manager? Does Session Manager do something like grab references to existing objects in FF, or does it replicate the data into its own data structures? Maybe those structures could be more compact or perhaps memory isn't getting freed after the replication.
zeniko wrote:...and set the maximum amount of saved POSTDATA to 0 which might also help.
Is that an overall setting or a per window/tab setting? Is it strictly POST data or does that also include cookies?
It was set to unlimited (the default, I presume). I set it to 4K, which I can't imagine having a significant impact on memory, and as I don't normally depend on Session Manager to save POST data, that should be adequate to save the state of a form in the event of a crash. (Though if that included cookies for all saved tabs, it's probably undersized.)
BTW, you have an "oldest to newest" option for ordering the session list; if that's selected, it'd be helpful if you scrolled the session selection list to the end of the list to show the most recently saved session.
zeniko wrote:tmetro wrote:I've noticed on several occasions on startup that I'll be prompted by Session Manager to select a session, then a minute later I'll be prompted again...
Are you saying that you get the recover session dialog twice when you start Firefox?
Yes. Bug?
-Tom