[gs-bugs] [Bug 692611] ps2pdf is 40 X slower in gs 9 than gs 8

[bugzilla-daemon at ghostscript.com]

http://bugs.ghostscript.com/show_bug.cgi?id=692611

--- Comment #7 from William Bader <williambader at hotmail.com> 2011-10-20 18:15:34 UTC ---
I built more versions of gs to narrow down the cause of the regression.

It was introduced in gs8.56.

gs8.54 processes the file in 3 minutes.
gs8.56 processes the file in 32 minutes.
(There was no gs8.55 release.)

(I rebuilt these with gcc-4.6.1, which generates code about 25% faster than the
gcc 3.3 or 3.4 that I originally used to build the gs8 releases that I timed in
the other comments where gs8.33 took 3.7 min and gs8.57 took 40 min.)

I compared the gs8.54 and 8.56 source.

The most likely cause is a redesign of color space objects as described in a
comment in gs8.56/src/gscspace.h:
 * Previous versions had a complicated lifecycle discipline for
 * colorspaces. All that is now replaced with a simple allocation and
 * reference counting discipline. All colorspace objects are allocated
 * on the heap and reference counted. References to colorspace objects
 * are pointers. There is no stack allocation, inline allocation inside
 * structs, or copying of contents.

A less likely cause is a change in the implementation of restore objects as
described in a comment in gs8.56/src/isave.h:
 * In PLRM3, Adobe did the reasonable thing and changed save objects to
 * composite.  However, this means that 'restore' must treat save objects on
 * the stack differently in LL2 vs. LL3 (yes, the Genoa LL2 and LL3 tests
 * require this!).  See zvmem.c:restore_check_stack.

William

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.