Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!bu-cs!purdue!decwrl!labrea!polya!ali
From: ali@polya.STANFORD.EDU (Ali T. Ozer)
Newsgroups: comp.sys.amiga.tech
Subject: Re: A Modest Proposal (IFF QuickDraw)
Keywords: PostScript
Message-ID: <2876@polya.STANFORD.EDU>
Date: 21 May 88 15:01:11 GMT
References: <4607@super.upenn.edu> <4WWCvzy00VoDA-hXlh@andrew.cmu.edu> <3974@gryphon.CTS.COM> <132@amtfocus.UUCP> <2542@utah-gr.UUCP> <10135@agate.BERKELEY.EDU>
Reply-To: ali@polya.Stanford.EDU (Ali T. Ozer)
Organization: Stanford University
Lines: 25

In article <2542@utah-gr.UUCP> John M. Olsen writes:
>PostScript is a postfix language (hence, the name) so it is interpreted
>instead of compiled, but I will leave the pros/cons of this alone for now.

The speed of the interpreter is sometimes the problem. In most of the
Postscript programs I've written, usually the speed of clipping, the
scaling/rotation of fonts, and the download time of binary images have
been the limiting factors.

In any case, you can pretty much eliminate most of the interpreter overhead
with the use of the often-ignored "bind" operator: It causes all the
executable operators in a Postscript procedure to be replaced by the
actual addresses, thus avoiding the time the interpreter would have
take looking up the name. The gain is immense if you happen to be
looping many times, using the same set of names. The disadvantage is
a loss in flexibility. 

Postscript is great --- gives you device independence, any size fonts,
arbitrary scaling, rotation, etc. The biggest problem is that it
requires a bit too much CPU. Other problems people point out (such as
"difficult to program" or "is interpreted") aren't really problems;
you can solve the first one through a layer of translation, and the
second one as shown above...

Ali Ozer, ali@polya.stanford.edu