Bug 689206 - PDF Performance very slow
Summary: PDF Performance very slow
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Graphics Library (show other bugs)
Version: master
Hardware: All All
: P2 normal
Assignee: Ray Johnston
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-02 08:52 UTC by Ray Johnston
Modified: 2020-06-01 10:02 UTC (History)
1 user (show)

See Also:
Customer: 190
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ray Johnston 2007-05-02 08:52:07 UTC
The customer reports that this file (the same one as for 689189) takes
a long time to RIP to the tiff32nc device. From the customer's report:

I get 2'35 to render it at 72 dpi, with tiff32nc as output, whereas all other
software I tried (Acrobat, Jaws, or the native previewer of MacOS X) makes it in
a few seconds.

This is with gs 8.53. I've tried also with 8.56, but it's not better - even a
little bit slower.

I've read here and there in various discussions and document that gs had bad
performances with shadings, so I suppose that this is more or less a known
problem (In the original Illustrator file, there are a lot of gradient objects
defined with the multiply  operator. I suppose this is one way to do shadings).

There is, however a second problem with this file: the color conversion
procedures (registered with get_color_mapping_procs) are called an incredible
number of times. For example at 72 dpi there are only 2.200.000 pixels, but
146.000.000 color conversion calls!

We really have a problem compared to our competitors here. To give you an order
of idea, at 600 dpi we rip this file in 30 minutes, whereas with Jaws
 on the same hardware exactly, it's 20 seconds... And this at
100% scale, but in fact originally the customer wanted to print at 500%. He
should have waited something like 12 hours.
-----

I have confirmed that with 8.56 this takes 131 seconds on a 2GHz Core Duo.

Current version (rev 7892) takes 60 sec on the same machine, so recent patches
have made some improvement, but this is still much slower than the competition.
Comment 1 Ray Johnston 2007-05-02 08:54:53 UTC
Created attachment 2930 [details]
Anniversaire.pdf

Same file as for bug 689189, placed here for convenience.

command line used for testing was:

gswin32c -sDEVICE=tiff32nc -o ann.tif -r72 -dBufferSpace=40000000
Anniversaire.pdf
Comment 2 leonardo 2007-05-28 03:45:31 UTC
Ray,

Please provide a clear complete information for this bug.

1. The bug discription says about 600dpi, but the command line in Comment #1 
specifies -r72. Which resolution does the customer need exactly ?

2. Please attach Jaws raster with same resolution and its timing. I need to 
compare the rendering quality.

3. Please note that tiff32nc -r600 generates a 630 Mb file. Adobe spends a 
minute just for opening it. In same time ppmraw generates 459 Mb some faster. 
The disk i/o speed may be important. A simple copying it to another phisical 
IDE HDD took 45 seconds.

4. Can you please give more PDFs with shading performance problem ? This one 
includes 8000+ degenerate shading instances, so I'm not sure which is the best 
way for its optimization. There are several ways, each of which is pretty 
heavy, so more examples would help to choose the best one.

Returning to Support.
Comment 3 Henry Stiles 2008-05-07 15:43:37 UTC
> I have confirmed that with 8.56 this takes 131 seconds on a 2GHz Core Duo.
>
> Current version (rev 7892) takes 60 sec on the same machine, so recent patches
> have made some improvement, but this is still much slower than the 
> competition.


Ray, that is true but the customers concern seems to be with an order of
magnitude difference that existed before.  That is what motivated the bug and
that issue is addressed.  If developers or customers want to report want to
report a new performance problem a new bug should be made.