Path: 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: Date: 10 May 91 03:17:41 GMT References: <1991May5.010114.24826@neon.Stanford.EDU> <488@heaven.woodside.ca.us> <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. In article <1998@chinacat.Unicom.COM> woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) wrote: > In article , 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