Path: utzoo!attcan!uunet!husc6!bloom-beacon!apple!bionet!ig!agate!ucbvax!decwrl!adobe!ondine!greid
From: greid@ondine.COM (Glenn Reid)
Newsgroups: comp.lang.postscript
Subject: Re: An Idea to Help Make Postscript Easier to Read (and Write)
Message-ID: <4218@adobe.COM>
Date: 10 Sep 88 17:26:24 GMT
References: <940@helios.ee.lbl.gov> <5361@vdsvax.steinmetz.ge.com> <1619@crete.cs.glasgow.ac.uk>
Sender: news@adobe.COM
Reply-To: greid@ondine.UUCP (Glenn Reid)
Organization: Adobe Systems Incorporated, Mountain View
Lines: 66

You people tend to forget that the PostScript language is interpreted.
It is well and good to use tools to convert to and from PostScript,
but it is not quite as "transparent" as we all might think.

I like to think of a big grandfather clock, with the pendulum swinging.
Each time pendulum swings, the PostScript interpreter gets to do one
operation.  The "granularity" of the clock is nowhere near the speed
of a microprocessor instruction set, and any comparison with assembly
languages doesn't make sense.

The difference between:

	0 0 moveto

and

	0 0 /arg2 exch def /arg1 exch def arg1 arg2 moveto

can sort of be measured in "ticks" of the interpreter's clock.  It's
not quite this simple, since simply pushing a literal is faster than
executing a real PostScript operator, but it is a rough rule of thumb.
It will take about three times as long to execute the second of these
in a tight loop, and about five times as long if it is transmitted and
scanned each time.  My rule of thumb is that if you have roughly the
same number of tokens in your stack approach as you do with your 'exch
def' approach, the 'exch def' is likely to be much more readable and
better.  Otherwise, I usually go with the stack approach.

One other thing of note is that if you have too much stack manipulation
going on, it may well be symptomatic of a problem in the original program
design.

Also, most procedures don't do any stack manipulation at all, they
simply use their arguments directly from the stack.  In this situation,
it is especially wasteful (and confusing, I think) to declare
intermediate variables.

Compare:

% sample procedure call:
	(Text) 100 100 12 /Times-Roman SETTEXT

% approach 1:
	/SETTEXT { %def
	    findfont exch scalefont setfont moveto show
	} def

% approach 2:
	/SETTEXT { %def
	    /arg5 exch def
	    /arg4 exch def
	    /arg3 exch def
	    /arg2 exch def
	    /arg1 exch def
	    arg5 findfont arg4 scalefont setfont
	    arg2 arg3 moveto arg1 show
	} def

Which of these is easier for you to understand?

Anyway, I think the discussion is a good one, but let's not forget
that PostScript it is an interpreted language.  And I don't think
it is terribly hard to use and understand, if it is written well.

Glenn Reid
Adobe Systems