Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!jarthur!nntp-server.caltech.edu!nntp-server.caltech.edu!daveg From: daveg@near.cs.caltech.edu (Dave Gillespie) Newsgroups: comp.emacs Subject: Re: Byte-compile summary. Message-ID: Date: 18 Oct 90 02:57:31 GMT References: <1162@red15.qtp.ufl.edu> <13937@ists.ists.ca> Sender: news@nntp-server.caltech.edu Organization: California Institute of Technology Lines: 63 In-Reply-To: kim@Software.Mitel.com's message of 17 Oct 90 13:28:02 GMT Nntp-Posting-Host: near.cs.caltech.edu I had a few comments about Kim Letkman's posting concerning whether it is wise to optimize byte-compiled code for speed. First, it's worth recalling that this issue came up because someone had an ELisp program which was uncomfortably slow. It's clear that, even if ELisp is plenty fast for many of the tasks to which people have applied it, there are other tasks which do push it to the limit. My Emacs Calculator is, as far as I know, by far the largest and probably the most computation-intensive Emacs program out there. When I originally wrote it it was uncomfortably slow; a careful reading of the implementations of the Lisp compiler and runtime system allowed me to speed it up by a factor of, roughly, five. This speed-up made the difference between "annoyingly slow" and "pleasantly fast" for simple operations in that program. It made the difference between "impractical" and "practical" for more advanced operations. Many people use Calc for jobs like summing columns of numbers from an Emacs file. That was the original reason for implementing it as part of Emacs, after all. These jobs can use all the performance they can get because the time they take scales with the size of the problem. Many existing ELisp programs share this property, and many others unnaturally constrain themselves to avoid it so that they will still be usable for large inputs. Every extra bit of speed squeezed out of ELisp allows these programs to provide more capabilities to their users. Many of the "useful and innovative functions" Kim asks for would not be practical if the foundations on which they were built were not solid and efficient. Yes, the FSF *could* change the byte-compiler tomorrow and much of the gains I got with Calc would be lost. But in practice, that won't happen tomorrow. Suppose it happens a year or two from now; during those years many people will have been able to do things with Calc that would otherwise have been impractical if I had not put in the extra effort to make it fast. Even if two years from now that effort is made pointless, I still think it was worth it overall. Emacs Lisp will not be around forever, nor will any language in use today. Even aside from optimization issues, any program you write in these languages has a limited lifetime. But that's no excuse to give up and never write anything new. There's no question that it's good to plan for the future, but if you ignore the here-and-now your program won't be around in the future anyway. 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. -- Dave -- Dave Gillespie 256-80 Caltech Pasadena CA USA 91125 daveg@csvax.cs.caltech.edu, ...!cit-vax!daveg