[gs-bugs] [Bug 691978] Performance problem reading PostScript file

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Thu Feb 17 13:58:39 UTC 2011


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

--- Comment #4 from Marcos H. Woehrmann <marcos.woehrmann at artifex.com> 2011-02-17 13:58:37 UTC ---
Ken:

It turns out that the reason we spend so much time in the garbage collector is
because the job tells us to!

Running grep over the file, looking for 'vmreclaim' results in 11369 hits. As
far as I can tell easily each of these is '2 vmreclaim' which means 'perform
immediate collection in local and global VM'.

This is of course an *extremely* expensive operation, as the interpreter must
examine the entire memory allocation looking for objects which can be
discarded. The PLRM is pretty clear that there really is no good reason to use
vmreclaim, the only time it can be used like this is in an interactive
application which can use idle time to clean up memory. There is *no* sense in
using it as this job does.

FWIW this appears to be because the job uses *many* patterns and each pattern
does an immediate vmreclaim.

All that being said, the output looks (to me) like it is generated from Adobe
Acrobat, so I think we need to be prepared for more jobs like this, though
probably without quite so much insane use of patterns.

Defining /vmreclaim as a no-op considerably improves the performance of this
job, Chris tells me it goes from ~30 minutes to 57 seconds by doing so.

I think we should consider defining vmreclaim as a no-op (by changing the C
source code to zvmreclaim) so that we ignore values of 1 and 2 (immediate
reclamation).

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


More information about the gs-bugs mailing list