> This is *not* a bug!
You misunderstood. Any changes you want to done to the source need a bug
number and a patch in bugzilla. In this case an enhancement bug which I at
least would decline. So this leaves the documentation.
FRG
Dirk Munk wrote:
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
