On Wed, Jan 04, 2006 at 08:06:20PM -0500, C. Scott Ananian wrote: > I tracked this problem down to a missing '--enable-maxmem=16' on the > ./configure command line. The parameter specifies (in megabytes) the > maximum amount of main memory libjpeg should allocate before creating > backing store on disk; 8, 16 or 32 seem to be reasonable values for modern > hardware. And if you don't like it, you can always either set JPEGMEM > in the environment or use the -maxmemory command-line parameter. > > Making this change has a huge impact on the usability of my linux 2.6.15 > machine with 320M of main memory when dealing with huge (11M or so) JPEG > files. jpegtran is *much* faster (tested with -maxmemory=64m) with the > 'ansi' memory manager and a limited main memory size than it was beofre > (with the 'nop' memory manager and >400M virtual memory allocated). > Because libjpeg is used throughout the system, I expect this will help fix > performance problems with large jpeg files throughout debian.
Hello Scott, Apparently it did not have precisely this effect, since I get three independant report of major slowdown, see bug #356556 and #365025. 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. Thanks in advance, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
