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 19:34:32 GMT References: <1162@red15.qtp.ufl.edu> <13937@ists.ists.ca> Sender: kim@spock Organization: Public Switching, MITEL Corporation, Kanata, Ontario, Canada Lines: 58 In-reply-to: worley@compass.com's message of 18 Oct 90 13:39:25 GMT In article worley@compass.com (Dale Worley) writes: | In article kim@Software.Mitel.com (Kim Letkeman) writes: | I can not remember ever saying to myself "geez, I wish that had been code more efficiently .... it's taking too many seconds." | | Try byte-compiling the Emacs lisp directory! :-) I do. It doesn't take all that long when one considers the amount of work happening ... but I suppose I should come clean now and mention that I've been using a Sparc 1+ for months now ... maybe that's why I consider emacs to be efficient enough. | Seriously, Kim, if Emacs were always fast enough in practice, there'd | be no need for a byte compiler at all. I've had days when C-n can | take noticable time, and I've used packages that can be agonizingly | slow even when the hardware is otherwise unloaded. I disagree with this. It is always a good idea to use a generic mechanism that is applied in a consistent manner to obtain a known increase in performance. That is one of the many reasons for using compilers in the first place. But when one "hand compiles" (i.e. uses less obvious algorithms) to attain higher efficiency than afforded by the compiler, then I submit that the compiler needs fixing, not the code. | One interesting thing about Sullivan Beck's list of ideas is that many | of them are things the byte-compiler could do for you. Putting the | optimizations in the byte-compiler saves a lot of work -- optimizing | the bytecode is done only once, and the application programmers can | spend their time on new features. Unfortunately, nobody has spent the | time to upgrade the byte-compiler to squeeze out improved performance | from the generated bytecode. Exactly. Although in a previous posting I concurred with the author of the calculator mode that there were certainly circumstances under which one can justify prying the lid off of a compiler, it simply is not the way to go for the general population at all times. Much better that the same people spend their time lobbying the FSF to do these optimizations internally so that common or natural ways of doing things are as fast as specialized methods. Or better yet - someone help them out and do the optimizations to the byte compiler for the good of gnu emacs weenie-kind. I'm sure we'd all appreciate it. By the way, my opinions are not intended to sell short the value of the information on the byte compiler's internals. But rather to express the idea that, in a situation where you have the option of fixing all the code that gets compiled or fixing the compiler, well, there's not much to choose .... Kim -- Kim Letkeman kim@software.mitel.com uunet!mitel!spock!kim