The defaults are in the source in suite\browser\browser-prefs.js
FRG
Dirk Munk wrote:
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
