Created attachment 26619 [details] test file to show slowness I use gs as packaged by Debian, currently version 10.0.0, and recently observe that gs -sDEVICE=bbox can be pathologically slow: on the file attached as example it takes about 20 seconds. Within my printing setup I had been using gs to count pages in PS files with something like gs -P- -dSAFER -o - -sDEVICE=bbox file.ps 2>&1 | \ grep HiResBoundingBox | wc -l Recently noticed that for some print jobs, gs took up to 10 minutes. (Seems this happens most often for PDF files sent as PS from Macs.) This is a recent issue, not sure whether triggered by some update on Mac, or of ghostscript. Noticed that ps2ps is also slow on these files, not as dramatically as BBOX; using gs to show on screen is fine, takes under 0.5 seconds. Issue reported to Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102270 Thanks, Paul -- Paul Szabo psz@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of Sydney Australia
(In reply to Paul Szabo from comment #0) > Within my printing setup I had been using gs to count pages in PS files > with something like > > gs -P- -dSAFER -o - -sDEVICE=bbox file.ps 2>&1 | \ > grep HiResBoundingBox | wc -l If all you want this for is to count pages then you should significantly reduce the resolution. The bbox device operates at a default resolution of 4000 dpi, because that gives better (in some cases, MUCH better) accuracy when determining the bounding box of the marks on the media. But it is, of course, slower. Running at (for example) 72 dpi will still give the correct number of pages but will be much quicker. > Recently noticed that for some print jobs, gs took up to 10 minutes. > (Seems this happens most often for PDF files sent as PS from Macs.) > This is a recent issue, not sure whether triggered by some update on > Mac, or of ghostscript. Noticed that ps2ps is also slow on these files, > not as dramatically as BBOX; using gs to show on screen is fine, takes > under 0.5 seconds. You have not said what earlier version you are comparing against, which makes comparison difficult. I have run your file and command line against versions I happen to have available, going back as far as 10 years, and I do not see a problem. My results are (total time is divided by 5 because I ran the file 5 times for more reliable results): 8:58:51.58 Starting test 10.05.0 8:59:33.00 Done 42 = 8.4s 8:59:33.00 Starting test 10.00.0 9:00:11.94 Done 38 = 7.6s 9:00:11.94 Starting test 9.55.0 9:00:53.84 Done 42 = 8.4s 9:00:53.84 Starting test 9.51 9:01:36.35 Done 43 = 8.6s 9:01:36.35 Starting test 9.25 9:02:14.06 Done 38 = 7.6s 9:02:14.06 Starting test 9.18 9:03:26.13 Done 72 = 14.4s So the only significant difference I see is that 9.25 and better are twice as fast as 9.18. On my setup Ghostscript is taking around 8 seconds to complete a single run, which is somewhat faster than you say you were seeing but will obviously depend on the machine in question. For a comparison an Intel NUC running Linux Mint (but built from source, not a package) takes 13.6 seconds to do the same job. While this may seem 'pathologically slow', it does not appear to be any different to the result of earlier versions of Ghostscript. Obviously it is possible that the package maintainer for the package you are using did previously use a lower default resolution. Note that rendering to the display device will be done at the display device resolution, usually 96 dpi, and I would expect that to be (considerably) faster than the default resolution of 4000 dpi used by the bbox device. Depending on your system you may be able to run to the display device at 4000 dpi (-r4000) to do a speed comparison. Or, as noted above, run the bbox device at a lower resolution. Either should demonstrate that the two are comparable when run at the same resolution. The ps2write device uses a default resolution of 720 dpi, so unsurprisingly will lie somewhere between the (probably) 96 dpi of the display device and the 4000 dpi of the bbox device. In short, I don't see a problem here.
Thank you for the explanation. (I do not know what default resolution may have been used in the past.) Sorry about the noise.