Frank-Rainer Grahl wrote:
Dear Frank-Rainer
This is *not* a bug!
It's very simple, if you open more tabs, you will need more memory. The
default memory setting simply is not sufficient for 'power users' with
many tabs open.
What I see here is what I've seen many times before. In a 32 bit
environment, memory constraints are very important, on OS level and
application level. All kinds of settings are done with the mindset of
conserving memory.
When the OS or the application is moved to 64 bit, very often no one
thinks about removing memory constraints, so applications still run as
if they were 32 bit applications. What should be done is checking all
kind of memory settings, and change these settings to let them use
(much) more memory. After all, that is the only purpose of 64 bit
operating systems and applications, make it possible to use more memory!
I've worked with very big computer systems, and almost every time when
there was a performance problem, it was due to memory conserving
settings. Database caches, not enough semaphores allocated for the
operating system, insufficient number of buffers for network and SAN
adapters, insufficient memory for sort procedures, not enough memory for
the Java Virtual Machine, the list goes on and on.
My friendly advise to the Seamonkey developers would be to go over all
the settings, and remove memory constraints. Yes, it will increase the
memory footprint of 64 bit Seamonkey, but if a user has a problem with
that, he should increase the memory in his system, or stick to the 32
bit version.
My experience with removing memory constraints is that applications
become much more stable as well. No hangs, no crashes etc.
By the way, if Seamonkey could use large pages, that could improve speed
and stability as well. I've set up my Windows account to enable large pages.
Personally I won't do any pref change in SeaMonkey here and would
advice to close any possible bug which asks for it.
These are Gecko backend settings and we usually don't touch them
unless they break us. Except the occasional change now and there.
But if some see a significant performance impact when changing this it
might be best do add something to the release notes. Happy to put a
small explanation into the next one if someones sends a snipplet to me.
FRG
Paul B. Gallagher wrote:
Yesterday, I wrote:
Pref set to 1048576. Let's see what happens.
OK, 24 hours of life with a larger memory cache have shown:
1) No dramatic improvement in overall performance;
2) A lack of hangs when SM reaches 25% CPU usage -- it hasn't reached
that level during the test period. Rather, it seems to peak at 15–18%.
So there may well be something to what Dirk Munk advised. I'll keep
running with this pref setting and watch for the hangs I used to get
regularly. When opportunities arise, I'll push it harder.
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
