[gs-bugs] [Bug 690665] MuPDF uses a lot of memory for large images

bugs.ghostscript.com-bugzilla-daemon at ghostscript.com bugs.ghostscript.com-bugzilla-daemon at ghostscript.com
Wed Jul 29 10:32:41 PDT 2009


http://bugs.ghostscript.com/show_bug.cgi?id=690665





------- Additional Comments From ray.johnston at artifex.com  2009-07-29 10:32 -------
As Tor points out, this PDF is nothing but one big JPEG compressed image.

On my laptop (2GHz Core 2) it takes 36 seconds to write the 455Mb clist (this
works out to about the size of the uncompressed image) and completes to png16m
600 dpi in 459 sec (434 Mb png file).

Using -dNumRenderingThreads=2 completes in 337 sec. I tried this on my Quad core
3.2GHz machine with RAID-5 yet (peeves) and with -dNumRenderingThreads=4 it
completes in 171 sec (5 sec to write the clist). On peeves, it took 189 sec
without -dNumRenderingThreads=4.

Thus GS can be sped up by using -dNumRenderingThreads=# where # is the number
of cores on the processor. Getting a faster machine helps a lot too :-)

The speed up is not very significant when using 4 cores probably because most
of the time is spent doing the PNG compression which is _not_ multi-threaded
by -dNumRenderingThreads=4. Running to the ppmraw device -o /dev/null on
peeves completes in 10 sec (24 sec cpu time) which shows the processing time
in GS without the PNG compression

Also, building gs with 'BAND_LIST_STORAGE=memory' make option will speed
things up since it won't need to write the 450Mb clist out to disk, but this
is not really the bottleneck.

All in all, it seems that things in both GS and MuPDF are working reasonably
as expected. I would like to know the comparative timings of muPDF vs gs.

I guess this bug can remain open for Tor to track the needed improvement to
incrementally load images.



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.



More information about the gs-bugs mailing list