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.