gs 9 is TEN times slower than gs 8.71 and generates an eps file that is almost 5 times larger. I have a script that converts PDF files to EPS files. It ran in an acceptable time with gs 8.71, but it began taking too long when I updated to gs 9. I tracked it to some PDF files that now take much longer. I had to revert to gs 8.71. I have some tests with a representative PDF file. The file is black and white, so I think that the ICC changes shouldn't be an issue. The time with the ppmraw device is about the same from 8.71 to 9, so I suspect that the problem is with epswrite rather than another component of gs or how I did the build. When I add -r600, gs9 is almost 15 times slower than gs 8.71. Did something change with the way that gs writes bitmaps? William gs 9 is over 10 times slower converting a PDF to an EPS with epswrite, and the resulting eps is almost five times as large. $ /usr/bin/gs -v GPL Ghostscript 8.71 (2010-02-10) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. $ /usr/local/bin/gs -v GPL Ghostscript SVN PRE-RELEASE 9.01 (2010-09-14) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. $ time /usr/bin/gs -q -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=temp0.eps 601.PDF real 0m0.902s user 0m0.827s sys 0m0.074s $ time /usr/local/bin/gs -q -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=temp1.eps 601.PDF real 0m11.786s user 0m11.606s sys 0m0.118s $ ls -l temp0.eps temp1.eps -rw-rw-rw- 1 william william 10253829 Jan 28 03:39 temp0.eps -rw-rw-rw- 1 william william 47436513 Jan 28 03:39 temp1.eps The times are about the same with the ppmraw device. $ time /usr/bin/gs -r600 -q -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=ppmraw -sOutputFile=temp0.ppm 601.PDF real 0m3.762s user 0m1.075s sys 0m0.510s $ time /usr/local/bin/gs -r600 -q -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=ppmraw -sOutputFile=temp1.ppm 601.PDF real 0m3.725s user 0m1.096s sys 0m0.507s $ ls -l temp0.ppm temp1.ppm -rw-rw-rw- 1 william william 261439559 Jan 28 03:54 temp0.ppm -rw-rw-rw- 1 william william 261439575 Jan 28 03:55 temp1.ppm For epswrite, adding -r600 makes epswrite slightly faster with gs 8.71 and slightly slower with gs 9, so gs 9 is almost 15 times slower. $ time /usr/bin/gs -r600 -q -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=temp0a.eps 601.PDF real 0m0.825s user 0m0.754s sys 0m0.070s $ time /usr/local/bin/gs -r600 -q -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=temp1a.eps 601.PDF real 0m11.792s user 0m11.462s sys 0m0.156s $ ls -l temp0a.eps temp1a.eps -rw-rw-rw- 1 william william 9833131 Jan 28 03:58 temp0a.eps -rw-rw-rw- 1 william william 46612187 Jan 28 03:59 temp1a.eps I tested with a gs9.01 pre-release, but gs9.00 has the same performance issue. $ /usr/local/bin/gs900 -v GPL Ghostscript 9.00 (2010-09-14) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. $ time /usr/local/bin/gs900 -r600 -q -dBATCH -dNOPAUSE -dEPSCrop -sDEVICE=epswrite -sOutputFile=temp1a.eps 601.PDF real 0m12.180s user 0m11.831s sys 0m0.232s pdftops from poppler processes this file faster than gs 8.71 and produces a smaller file, so I do not think that this PDF does anything especially expensive. $ pdftops -v pdftops version 0.15.3 Copyright 2005-2010 The Poppler Developers - http://poppler.freedesktop.org Copyright 1996-2004 Glyph & Cog, LLC $ time pdftops -eps 601.PDF temp2.eps real 0m0.503s user 0m0.480s sys 0m0.023s $ ls -l temp2.eps -rw-rw-rw- 1 william william 3343585 Jan 28 04:16 temp2.eps
Created attachment 7164 [details] PDF to show the problem
(In reply to comment #0) > I have some tests with a representative PDF file. The file is black and white, > so I think that the ICC changes shouldn't be an issue. In fact this does look like it *is* something to do with ICC profiles. Although the content of the PDF may appear to be monochrome, there is no monochrome colour space, so the content must be defined in DeviceGray. The ICC code covers *all* colours, even gray. The issue seems to be some form of complexity problem. Not only is the performance degraded, but the output file size is considerably bigger. I haven't yet had a chance to check on why this is so. If you only want PostScript output I would suggest using ps2write instead for now.
Thanks for looking at it. >If you only want PostScript output I would suggest using ps2write instead for now. I need EPS because the files are images that I need to place on a page. More specifically, the files are advertisements that I am placing on newspaper pages. Some come as PDF, and I use a batch script that uses gs to convert them to EPS. With gs9, the script does not finish within the deadline to make the pages. >In fact this does look like it *is* something to do with ICC profiles. If it is something that I might have a chance of fixing, can you give me a suggestion of where to look? Is it possible to disable the use of ICC from the command line at run-time or from a configure option during the build? Disabling ICC would give a way to show if it is the problem, and it would be a temporary work-around if it is the problem. William
(In reply to comment #3) Although ps2write produces DSC compliant PostScript now, it doesn't yet produce EPS files, so you can't realistically use it. > >In fact this does look like it *is* something to do with ICC profiles. > > If it is something that I might have a chance of fixing, can you give me a > suggestion of where to look? I don't think you'll be able to fix it, and I'm not certain myself what's happening. What I see is that at least one and possibly several images are not remaining as image data. Each sample in the image is being converted to a filled rectangle. Obviously a construct of the form: set colour x y width height rectangle fill Is a *lot* bigger than a simple byte containing the image data. Or even worse a single bit if its truly monochrome (images *can* have 1 bit data, even though they are still specified in DeviceGray space). This takes a lot longer to write out (the current output is at least 5 times larger) and may also take longer to generate internally. > Is it possible to disable the use of ICC from the command line at run-time or > from a configure option during the build? As far as I'm aware, no, neither is possible. I will put it to our colour expert though in case I'm wrong.
On the support call, we discussed that we probably should make a ps2write variant that writes EPS conforming output. This bug is already 'enhancement', so we will just leave it open until we get around to a eps2write
eps2write now exists.