On Wed, 3 May 2006, Bill Allombert wrote:
So I am considering following Guido advice and set the default value
to 1024M (so JPEGMEM still work but the 'nop' memory manager is almost
always used).
However I am surprised the speed differences are so large, it looks
like the ansi allocator is very slow. Would you be willing to investigate
that issue ? The log of bug #356556 include a test image.
Well, both allocators will be equivalently fast, until you run out of
available memory. Then the ansi allocator will do a much better job
swapping to disk than linux's default memory manager, which will just
thrash randomly.
On the other hand, not swapping to disk is always faster than having to
swap (undoubtedly your bug reporters have lots of main memory and so don't
otherwise have to swap).
The "best" solution is to figure out how much available memory is on the
machine and set the cut off to that. This is a hard problem: how much of
the "free" memory in the system could safely be swapped? It might be
better to set JPEGMEM by default to some fixed fraction (25%?) of the
memory in the system -- which works unless the machine is heavily loaded,
etc.
One way or another, someone is going to have to set JPEGMEM -- either
those on small memory machines or those on large. The small memory
machines get completely unresponsive if JPEGMEM is too large (because they
swap uncontrollably), while the large memory machines just do things more
slowly than they would otherwise. That was my rational for setting
JPEGMEM at a relatively modest value. I don't have any vested interest in
one particular value over another, as long as the code is compiled so that
you can set JPEGMEM if you need to. It may well make sense to gradually
increase JPEGMEM as time goes on.
--scott
mustard ESGAIN SEQUIN ODENVY operative MKULTRA COBRA JANE shotgun
Noriega ZRMETAL operation Sigint ODEARL Waco, Texas PANCHO Diplomat
( http://cscott.net/ )
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
