Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!yetti!geac!orcisi!michael
From: michael@orcisi.UUCP
Newsgroups: comp.sources.d
Subject: Re: Postscript interpreter
Message-ID: <1009@orcisi.UUCP>
Date: Thu, 26-Nov-87 09:10:09 EST
Article-I.D.: orcisi.1009
Posted: Thu Nov 26 09:10:09 1987
Date-Received: Sun, 29-Nov-87 07:06:36 EST
References: <964@orcisi.UUCP>  <219@horizon.UUCP> <30@goose.UUCP>
Organization: Optical Recording Corporation, Toronto, Ontario
Lines: 23

> I can see two obvious suggestions:
> 1) The interpreter is not bit manipulation bound.
>    Sure, not entirely, but the top line of the prof(1)ile is
> 	 %time  cumsecs  #call  ms/call  name 
> 	  31.1    26.18                  _NotThisBit 
>    The second line incidentally is PanicIf.

On our Sun 3/160, Xvalue() was one of the greatest time consumers (and
easily macro-able).  I did my analysis with gprof.  I believe
Yintersect() and AddInteresting() were the next two candidates for
optimization.  I didn't keep the actual results around however.

These is an awful lot of subscripting used to access various array data
structures (i.e. using []).  Some of this occurs in loops that could be
easily re-coded to use pointers with incrementing.

Also, there is one spot where qsort() is called which results in many
calls to the "comparison function".  Re-coding this would help.  I
think this is the reason why I remember AddInteresting() being so
time-consuming.

These comments are intended to make this great implementation just
a little bit better.