| Summary: | Clist image storage could be improved. | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Ray Johnston <ray.johnston> |
| Component: | Graphics Library | Assignee: | Ray Johnston <ray.johnston> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | christinedelight.top85, shailesh.mistry |
| Priority: | P3 | Keywords: | discuss |
| Version: | master | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | casper.ghostscript.com:/home/support/690199/23066.pdf | ||
| Customer: | Word Size: | --- | |
| Attachments: | memfile-64-bit.patch | ||
|
Description
Ray Johnston
2008-12-11 09:13:31 UTC
The file is too large to attach to bugzilla, so please see the URL above. Note that the command line to reproduce the crash is: gswin32c -r200 -Z: -sDEVICE=png16m -o x.png -q 23066.pdf Ignore the comment about the file "wrapping" at over 4Gb. The tool I was using to watch the clist file size was limited and reporting the wrap. With the default BufferSpace, at 200 dpi, HEAD writes 18,876,192 KB clist file, beginning "Outputpage" at 526 sec on my 3.2GHz P4. WOW!!! It takes a LONG time to write the PNG file, but eventually completes in 2280 sec. I will try a larger BufferSpace next (the customer reports using 200 Mb) With: gswin32c -r200 -dBufferSpace=200000000 -sDEVICE=png16m -o x.png 23066.pdf The file begins the Outputpage at 312 seconds (on my 3.2 GHz P4 dual) and writes 11,278,116 KB of clist. The page is complete in 746 sec. With -dNumRenderingThreads=2 added to the above command line, the time up to Outputpage is (roughly) the same, but the render time is much longer, probably due to I/O contention caused by reading from two different non-contiguous areas of the disk. I will see if these results are consistent with 8.63 -- we may have improved some things since then. The problem is caused by writing uncompressed image data to clist. The documkemt defines 100+ images of the size 6000x6000x24. Thus the overall uncompressed size is about 12Gb. We have had a project of writing compressed image data to clist, but no progress yet. IMO it depends on writing high level color to clist. Besides that I think a division of image data for bands without a re-compression generally isn't possible. Likely we can own some code from pdfwrite. reassigned back to Ray. Created attachment 6428 [details]
memfile-64-bit.patch
I've discovered a problem that the changes to support 64-bit clist file
offsets to the BAND_LIST_STORAGE=memory were never completed when the
changes were made for 64-bit file I/O.
Since this customer uses BAND_LIST_STORAGE=memory, this may be a problem.
I am leaving this bug open to an an enhancement to compress data in the
clist. Further comments on compressed image data in the clist will be
added separately.
Fixing the priority and changing to enhancement, and fixing the subject. This is no longer a customer issue, but a placeholder for clist image storage improvements. Enhancement still missing in Ghostscript 9.03 This is no longer a problem. 96sec 32Mb: -r200 -sDEVICE=png16m -o x.png -Z: 23066.pdf 80sec 25Mb: -dBufferSpace=32m -r200 -sDEVICE=png16m -o x.png -Z: 23066.pdf Closing as FIXED. |