Path: utzoo!utgpu!cunews!spock!kim!kim From: kim@Software.Mitel.com (Kim Letkeman) Newsgroups: comp.emacs Subject: Re: Byte-compile summary. Message-ID: Date: 18 Oct 90 11:58:06 GMT References: <1162@red15.qtp.ufl.edu> <13937@ists.ists.ca> Sender: kim@spock Organization: Public Switching, MITEL Corporation, Kanata, Ontario, Canada Lines: 39 In-reply-to: daveg@near.cs.caltech.edu's message of 18 Oct 90 02:57:31 GMT In article daveg@near.cs.caltech.edu (Dave Gillespie) writes: | I don't recommend that people devote huge efforts to squeezing out | every last cycle in every part of their programs. I certainly don't. | But usually a few parts of a program do deserve that attention, and | it's just plain sloppy not to give it to them. And it's no great | strain to keep in the back of your mind that "nth" is faster than | "elt" and "cons" is faster than "nconc". If there's a fast way of | doing something and a slow way, it's only reasonable to expect to know | your tools well enough to choose the fast way. Emacs itself is only | fast enough to "tame the mundane aspects of programming" and "maintain | a liveable environment" because its author paid the same attention | to detail. I certainly grant that this attention to detail is what makes gnu emacs such a pleasure to use. And that equivalent attention to detail is what separates the good from the bad in software design in any field. I will also grant that those who take the time to understand a compiler can write more efficient code without penalty. And if one wants to commit to the upkeep necessary if the compiler changes (assuming that the author is not also the author of the compiler), then one can do as one pleases, and the users will benefit. My points actually stem from my experience in real-time systems. Attention to the macro rather than the micro algorithms and details is where the order of magnitude performace increases lie. Many performance problems result from poor design decisions, almost always the result of a lack of abstraction of the problem. Anyway, we're straying off topic in this group and I'll grant that your calculator benefited from the exercise, thereby validating this type of attention to micro-detail under the right circumstances. Kim -- Kim Letkeman kim@software.mitel.com uunet!mitel!spock!kim