The attached PDF file loads very slow in Ghostscript; the newer the Ghostscript the slower. Displaying the file on the screen at equivalent sizes (-r24 for Ghostscript): gs8.53 4:25 gs8.54 5:43 gs8.56 9:57 acroread 0:26 All of the results look identical.
Created attachment 2858 [details] 9322.pdf
We need to find out what causes the performance problem.
Acrobat 7 on WinXP spends 25 seconds to open it on a Zeon 3.05 GHz machine.
The document defines 250000+ images.
It is an image rendering problem. The last slowdown may be caused by the color space patch http://ghostscript.com/pipermail/gs-cvs/2007-March/007345.html (I didn't test for sure). Passing to image specialist.
Created attachment 3275 [details] patch Use inline and intristic functions to improve the speed of CIE cache set-up. This speeds up the sample file processing by 10% on GCC, release build. There's little room for further low level optimization. The sample file has a large number of small images that use ICCBased color space, the same for all images. Setting up CIE cache for every image takes about a half of the running time. We need to cache the CIE caches to achieve significant results.
The patch is committed as a rev. 8184. Regression testing shows no differences.
Looks like this is fixed.
Current HEAD takes about 1 hour to process the file on a mid-range PC. The main problem is not fixed.
This type of file (one with a lot of images with ICC profiles) will be handled much more efficiently when we implement the new ICC based work flow. The specification for this new flow is currently under development. The approach will be to have a small cache of recently used linked transforms that could be applied to the data in one single step, versus the multi-step transformation that occurs today for this case.
Reassigning to Dave to look at the primary source of delay in this file. It would also be interesting to see how this file behaves with the ICC branch.
Created attachment 5967 [details] PerformanceAnalysis.pdf The PDF attachment describes the performance problem. The function check_interpolation_required is called 2.3 billion times (it is inlined, but makes no difference), which appears to be excessive. The garbage-collection-related function gc_trace is also expensive, but I do not know whether this is a side effect of the aforementioned problem.
Since Michael is working on replacing ALL of the CIE code with ICC color conversion using 'link' profiles directly from the source to the destination color space, this is probably best left as a test for the ICC branch. Thanks for the analysis, Dave. If this runs on the icc_work branch, can try that and if it is still very slow, repeat the performance analysis?
With the merge of the icc branch, this renders in a reasonable amount of time. About 2 minutes at 72dpi and 2 minutes 30 seconds at 300dpi on my laptop (2.4 GHz 32 bit)
Changing customer bugs that have been resolved more than a year ago to closed.