Subject: Re: Enumerated symbols in lisp
From: Erik Naggum <>
Date: 1995/04/10
Newsgroups: comp.lang.lisp
Message-ID: <>

[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.

sufficiently advanced political correctness is indistinguishable from irony