Summary: | Conversion takes unusually long time | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | artifex |
Component: | PDF Interpreter | Assignee: | Default assignee <ghostpdl-bugs> |
Status: | NOTIFIED DUPLICATE | ||
Severity: | normal | CC: | tim.osborn |
Priority: | P2 | ||
Version: | 8.54 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Customer: | 870 | Word Size: | --- |
Description
artifex
2006-08-07 00:29:28 UTC
Created attachment 2401 [details]
Sample PDF for long conversion times
Confirmed with HEAD. Profiling using callgrind shows that a very significant amount of time is going into top_up_cbuf(), and in particular the memmove operation. Setting -dNOTRANSPARENCY increases the speed dramatically, probably at the expense of correct rendering. These results suggest that we have a generic performance problem with the low-level reading of the clist files, but that transparency operations especially exercise this problem. I recommend probing further into the clist_playback_band logic to see why it's calling top_up_cbuf so often, and with such large byte amounts of memmove. This appears to be a problem in the pdf interpreter as it is calling .inittransparencymask twice for each stroke when the PDF is using transparency. Created attachment 2885 [details]
One more sample that is rendered slowly
This is another sample that converts fast (24 seconds), but wrong with
-dNOTRANSPARENCY. It takes 570 seconds (about 23 times slower) to be rendered
correctly. Both conversions on the same machine with conversion to 300 dpi
tiffg4.
In revision 7883 the code in read_create_compositor of gxclrast.c was changed to only call top_up_buf when necessary. Previously it called it every time read_create_compositor was called. This change sped up the problem job to run in approximately 1/2 the time. Setting BufferSize to 40000000 sped up the job by another factor of approximately 10x. So this fix and the larger BufferSize parameter speed up the job by a factor of approximately 20x. Created attachment 2953 [details] Zipped PDF-file with slow rendering Please have a look at the enclosed PDF-file. There is no difference in performance between GhostScript 8.54 compared to GhostScript 8.56 with the patch that should increase performance by factor of 2. With -sDEVICE=tiff24nc -r100 -dBufferSpace=40000000 it takes about 750 seconds (more than 12 minutes). With additional -dNOTRANSPARENCY it takes only 24 seconds (factor 30). Our customer needs even much longer because he needs 300 dpi instead of 100 dpi in the example. Bug reopened because the attached PDF-file is also very slow rendered without -dNOTRANSPARENCY. Please verify if this file should also work better with the suggested patch. On my laptop (2GHz Core Duo) this file took 24m at -r100 (14m CPU time). The CPU time indicates there might be some I/O bottleneck. Note I tested rev 7952 with -dBufferSpace=40000000 But the 14m CPU-time are also quite large. You should also look for that. I have reproduced this problem. From my early tests it looks like it is spending the majority of the time in gc reclaim. I think we should close out this bug and create a new one with a single well defined problem. Apparently the original issue was fixed in 7883 and the customer reopened with a new test file probably demonstrating a different performance problem. I agree Based on the comments and my testing believe the first two files now have reasonable performance as far as the customer is concerned but the third does not. Accordingly I've opened bug 689534 with just that file. *** This bug has been marked as a duplicate of 689534 *** Changing customer bugs that have been resolved more than a year ago to closed. |