🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.postscript
Article #5618

Re: Bind problems

#5618
From: Jamie Zawinski
Date: Fri, 10 May 1991 03:17
48 lines
2813 bytes
In article <1998@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) wrote:
> In article <JWZ.91May6183906@thalidomide.lucid.com>, jwz@lucid.com (Jamie Zawinski) writes:
>> 
>> If you are writing a prolog that is large enough to be a transmission-time
>> hit in and of itself, like the prologs generated by most mac programs, and
>> by Adobe Illustrator, then you're doing something wrong already.  It's not
>
> I think that the prolog generaly is a small portion of the file.

I have seen many many (generated) files where the prolog was a staggering
amount larger than it should have been, like 800%.  There's no excuse.

> The deeper problem as far as transmission times go, is the many references
> to a variable name.  For example, if you have a variable called
> Current_X_Position  You have 18 characters.  If you use this each time
> you have to position a word on the page, it is going to add up to A LOT
> of transmission time, and space.  Much better to use X in this case.

Yes, I said this.

>  For a compiled language, it does not matter, as the variables are reduced
>  to memory locations at compile or link time, but for interpreters, it does
>  matter.  Lookups take time.  The scheme that Adobe uses, is fast, but still
>  takes time.
[...]
> In general, in an interpreter type language, the most frequently used
> variables should be as short as possible name wise, and the less frequently
> used variables should be longer.  

No!  These two pieces of code will run at exactly the same speed:

	/foo {
	  0 1 10 { /x x 1 add def } for
	} def

	/foo {
	  0 1 10 { /a-much-longer-name a-much-longer-name 1 add def } for
	} def

The second will take an infinitesimal amount of time longer to PARSE, but once
parsed, the executable array which the interpreter has a handle on contains
pointers to the name-objects themselves.  It does not have to parse the name
each time through the loop.

Anyway, I think an attempt to make a prolog section shorter by picking bad
variable names is misguided to say the least.

	-- Jamie
Technical Details
Message-ID: <JWZ.91May9221741@thalidomide.lucid.com>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!stanford.edu!lucid.com!campeau!jwz
References: <1991May5.010114.24826@neon.Stanford.EDU> <488@heaven.woodside.ca.us> <JWZ.91May6183906@thalidomide.lucid.com> <1998@chinacat.Unicom.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!stanford.edu!lucid.com!campeau!jwz
From: jwz@lucid.com (Jamie Zawinski)
Newsgroups: comp.lang.postscript
Subject: Re: Bind problems
Message-ID: <JWZ.91May9221741@thalidomide.lucid.com>
Date: 10 May 91 03:17:41 GMT
References: <1991May5.010114.24826@neon.Stanford.EDU> <488@heaven.woodside.ca.us>
 <JWZ.91May6183906@thalidomide.lucid.com> <1998@chinacat.Unicom.COM>
Sender: usenet@lucid.com
Organization: Lucid, Inc., Menlo Park, CA
Lines: 48
In-Reply-To: woody@chinacat.Unicom.COM's message of 10 May 91 03:50:23 GMT
X-Windows: A terminal disease.