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: 17 Oct 90 13:28:02 GMT References: <1162@red15.qtp.ufl.edu> <13937@ists.ists.ca> Sender: kim@spock Organization: Public Switching, MITEL Corporation, Kanata, Ontario, Canada Lines: 53 In-reply-to: mike@ists.ists.ca's message of 17 Oct 90 02:29:01 GMT In article <13937@ists.ists.ca> mike@ists.ists.ca (Mike Clarkson) writes: | | These pointers are very specific to the GNU elisp byte-compiler. One | of the fascinating things about lisp is how these trade-offs differ | from dialect to dialect, and implementation to implementation. This is | one of the things that makes lisp such a difficult language to program | *well* in. | I'm certain that these tips are appreciated by anyone who feels the "need for speed"@footnote{See TopGun}. But I feel compelled to point out that the main reason why we (in the general computer scientist sense) use high level languages is to take advantage of the built-in abstraction of data and process that comes with such a language. Elisp handles some extremely high level concepts with ease, and there is no shortage of excellent software to go with gnu emacs for that reason. Your earlier posting demonstrated an excellent knowledge of the inner workings of the Elisp byte compiler, which could potentially increase the performance of certain operations within any Elisp-coded functional unit within emacs. But emacs is extremely popular because of its power to tame many of the mundane aspects of programming and of maintaining a liveable environment. I'm one of those that starts up an emacs window covering the vast majority of my Sun workstation's screen area and then live in the editor, using gnus, VM and other ELisp-coded functional units to create an extremely pleasant and efficient environment. I can not remember ever saying to myself "geez, I wish that had been code more efficiently .... it's taking too many seconds." The reason for this is, of course, that my overall productivity is much higher inside emacs, so I am forgiving of some of the more time consuming operations (none of which even come close to being annoying anyway ....) Another problem with worrying these micro-details is that I'm sure that the FSF would not hesitate to change the way in which code is byte compiled if it could gain an overall performance advantage. For this reason, it is never a good idea to second guess any compiler. I guess I should make a point. I would like to see the authors of these packages spending their time coming up with more useful and innovative functionality, rather than spending time altering algorithms to attempt to take advantage of a quirk or two in the current byte compiler. There's simply no long-term payoff in it. (Especially when one considers the incredible performance leaps and bounds happening in hardware right now.) -- Kim Letkeman kim@software.mitel.com uunet!mitel!spock!kim