The conversion of the attached PDF-file takes an unusually long time. Command line on Windows: gswin32c -sDEVICE=tiffg4 -r300 -o takeslong.tif takeslong.pdf On a 3GHz Pentium 4 it takes more than 12 minutes, whereas other PDF-files require just a view seconds. Times are given just to compare usual conversion times against conversion times for this sample file. Our customer is doing the conversion on Solaris where he aborted the conversion after unacceptable 40 minutes. The problem seems to be independent of the operating system.
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.