David H. Durgee wrote:
Paul B. Gallagher wrote:
Dirk Munk wrote:
Paul B. Gallagher wrote:
Dirk Munk wrote:
I haven't mentioned stability until now, but with these settings
Seamonkey hasn't crashed these last days, and it used to do that
once or twice per day.
You may not have used the word "stability" in the bodies of your
messages, but when you put "stability" in the subject line and
"crash" in the body it's clearly what you're talking about.
My experience with SM has been different in that it has crashed only
a couple of times a year, usually for nonreproducible reasons. By
"crash" I mean "terminated without authorization," not "stopped
producing output and accepting user input," which has been happening
several times a day. I call that "hanging," because the program is
still running according to Windows Task Manager (which usually
reports "Not Responding"), and resumes normal operation after two to
five minutes. At those times, if I keep demanding a response with
mouse clicks, Windows will prompt me to wait or close the
unresponsive program. If I choose to wait, SM will eventually revive.
Once it does, a normal shutdown and restart of the program (including
automatic clearing of cache and cookies) will clean out the crud and
allow it to perform well for a while.
Since I increased the allowed memory cache size about a week ago, the
hangs have decreased drastically in frequency, but have not been
entirely eliminated. If I really push it, I can still get it to hang
occasionally. But it's a lot more pleasant to run.
For other users, I suspect some sources of hangs and crashes are
related to badly written ad scripts, but my ad blocker takes care of
most of those. And of course if I choose to walk on the sketchier
side of the Internet, it's easy to find sites that will serve malware
and obnoxious popups insisting that I need to install their
anti-malware programs. (Right. I was born yesterday. Well, I guess
"there's one born every minute.") But none of that is SeaMonkey's
fault, and a decent internet security program will take care of that.
Why don't you try all the other settings as well, and see what
happens. The network cache settings dramatically reduced CPU cycles,
and disabling the disk cache made Seamonkey much faster.
Proper experimental methodology would be to try them one at a time, so
we can tell which ones had which results. I did enable pipelining
yesterday; we'll see what that does.
After trying them one at a time it would next make sense to try them in
combinations to see which have synergy with others. It might be that
some are only effective in combination with other settings, while some
have similar impacts and might not reinforce or might even interfere
with one another.
Unfortunately much of this can probably only be determined by
experimentation and is likely to vary from Windows to linux to OS X
platforms.
Dave
It all starts with memory, memory, memory. The second thing is to avoid
disk access.
That is what you see in these settings.
First we increase the memory cache.It gives Seamonkey plenty or room to
cache all the web pages we want to see.
Then we disable the disk cache. With sufficient cache memory allocated,
we don't need it. It speeds up Seamonkey dramatically, even if teh disk
is a SSD.
Then we increase the network cache buffers. Seamonkey can now handle big
chunks of data in one time, and isn't interrupted all of the time
because the network buffer space is exhausted.
And finally we increase the pipeline request count. We In one request we
ask for maximal 64 items on a web page, they will be send to us one
after the other with great speed. The network cache buffers can catch them.
So, all of these parameters already are connected to each other.
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
