Frank-Rainer Grahl wrote:
> 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
I'm not referring to the source, I'm referring to the configuration file
at the moment.
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
