Bug 708416 - BBOX slow
Summary: BBOX slow
Status: RESOLVED INVALID
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PS Interpreter (show other bugs)
Version: 10.0.0
Hardware: PC Linux
: P2 normal
Assignee: Default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-04-07 00:18 UTC by Paul Szabo
Modified: 2025-04-07 21:13 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
test file to show slowness (717.83 KB, application/postscript)
2025-04-07 00:18 UTC, Paul Szabo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Szabo 2025-04-07 00:18:28 UTC
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
Comment 1 Ken Sharp 2025-04-07 08:33:22 UTC
(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.
Comment 2 Paul Szabo 2025-04-07 21:13:02 UTC
Thank you for the explanation.
(I do not know what default resolution may have been used in the past.)
Sorry about the noise.