Subject: Re: Enumerated symbols in lisp From: Erik Naggum <erik@naggum.no> Date: 1995/04/10 Newsgroups: comp.lang.lisp Message-ID: <3006511941.222137@naggum.no> [Mikael Wittberg] | I do not quite see why I should not worry about this one. Say if I | need to make 100 branches on 100 numbers each time: | | If the jump is represented by a table it will cost me: | 100 instructions. | | If the jump is represented by IF's it will cost me: | 100 * (100 / 2) = 5000 instructions on avarage. | | This makes the execution difference = 5000/100 = 50. Thus a program | using the first aproach may execute 50 times quicker than the latter | one. this is quite a difference I would say! | | Is it so that I can assume that a LISP compiler uses an efficient | algorithm to jump on large values? Can I assume for instance that some | kind of binary search is used? what would it take for you to be satisifed with an answer, Mikael? seems like you're increasing desperately trying to show that Lisp is a bad choice. were you forced to use Lisp by someone who didn't listen to your reservations? if so, don't take it out on Lisp, please. because the ability to reason about a Lisp program is so much higher than, e.g., C programs, a compiler can be made arbitrarily intelligent and optimizations could conceivably counter-act premature optimizations made by programmers used to stupid compilers (that's you), in addition to make the most efficient code there is. you will find that run-time efficiency has a compile-time cost. if you want to fast compilation, you don't get fast execution. in most Lisp systems, you can tweak compiler speed, optimization, safety, etc, etc. have you tried to read the manual to investigate the differences caused by various compilation switches? see the chapter on Declarations in CLtL2. #<Erik> -- sufficiently advanced political correctness is indistinguishable from irony