Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!decwrl!adobe!heaven!glenn
From: glenn@heaven.woodside.ca.us (Glenn Reid)
Newsgroups: comp.lang.postscript
Subject: Re: Shorter version of PostScript "Recycle" symbol
Message-ID: <188@heaven.woodside.ca.us>
Date: 28 Jun 90 20:00:56 GMT
References: <6741@umd5.umd.edu> <185@heaven.woodside.ca.us> <6750@umd5.umd.edu> <186@heaven.woodside.ca.us> <6761@umd5.umd.edu>
Reply-To: glenn@heaven.UUCP (Glenn Reid)
Organization: Skyline Press, Woodside CA
Lines: 56

In article <6761@umd5.umd.edu> zben@umd5.umd.edu (Ben Cranston) writes:
>If the Illustrator prolog is always exactly the same, why bother to write
>it out into the save file at all?  I assume it is utterly ignored when a
>file is read in.  Then provide a separate program or a menu function to
>write "a *complete* postscript file", including the prolog.

Sounds like a great idea to me.  I've done it myself as a post-process, with
shell scripts, when I have lots of illustrations included in one larger
document (FrameMaker).

>BTW, is it really true that you can save execution time by using prolog
>procedures rather than the "raw" lineto, curveto, etc primitives?  Seems to
>me there's always got to be SOME intepreter overhead hit, and since the
>numbers always change you're not saving string-to-num time.  Can it really
>cost so much to lookup "lineto"?

Depends on whether or not they're really procedures; see below.

>Actually, assuming a one-for-one l == lineto c == curveto then there is
>exactly one lookup in either case.  So is there any runtime saving, or are
>you in fact trading runtime away for space with this simple-minded prolog?

When you do something like "/l /lineto load def" you set up the world so
that two names both point to the same operator:  "l" and "lineto".  These
take exactly the same amount of time to look up and execute, as you
mention, but the "l" takes 1/5 the space and 1/5 the transmission time
to get to the interpreter, and the scanner only has to read 1/5 as many
characters to read the name.  So you save execution time, but on the
front end, not inside the interpreter itself.

If you define a procedure like "/l { lineto } def" you actually LOSE,
because you incur two name lookups (once for "l" and once for "lineto"
inside the procedure) plus the procedure call overhead.  Using "bind"
helps a little bit.

But if the procedure is longer, and you use "bind":

	/f { gsave 1 setgray fill grestore stroke } bind def

it gets a litte more complicated.  You lose some on procedure overhead,
you gain lots in space savings and transmission time, and you save some
name lookup time since you used "bind" on the procedure.  All in all,
this is a WIN and is why the procedure mechanism exists to begin with.

When I looked through the recycle code, I noticed recurring patterns
of instructions and data which were `fixed'; perfect candidates to be
captured in a procedure.  Otherwise I just shortened the names of the
operators you called, saving a bit of space and transmission time, and
therefore making it execute a little bit faster.

/Glenn

-- 
% Glenn Reid				PostScript consultant
% glenn@heaven.woodside.ca.us		Free Estimates
% ..{adobe,next}!heaven!glenn		Unparalleled Quality