Summary: | Performance problems reading PDF file | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Marcos H. Woehrmann <marcos.woehrmann> |
Component: | Color | Assignee: | Michael Vrhel <michael.vrhel> |
Status: | NOTIFIED FIXED | ||
Severity: | normal | CC: | michael.vrhel |
Priority: | P2 | ||
Version: | 8.56 | ||
Hardware: | PC | ||
OS: | Linux | ||
Customer: | 850 | Word Size: | --- |
Attachments: |
patch
PerformanceAnalysis.pdf |
Description
Marcos H. Woehrmann
2007-03-26 19:56:20 UTC
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. |