[2-4] Is Lisp inherently slower than more conventional languages such as C?

This is a tough question to answer, as you probably expected.  In many
cases, it appears to be.  Lisp does not require the programmer to specify
the data type of variables, so generic arithmetic operators may have to
perform type checking at runtime in order to determine how to proceed.
However, Lisp code can also be denser (i.e.  there is more expressed in a
single line) than many other languages: the Lisp expression (+ A B) is more
powerful than the C expression A+B (the Lisp version supports bignums,
rationals, and complex numbers, while the C version only supports
limited-size integers and floating point); therefore, one may claim that it
is reasonable that the Lisp version take longer than the C version (but
don't expect everyone to accept this rationalization).  Solutions to this
include hardware support (e.g. processors that support type tags in data,
such as SPARC and Symbolics Lisp Machines), declarations, and specialized
variants of functions (e.g. in MacLisp, + accepts and returns only fixnums,
+$ accepts and returns only flonums, and PLUS is generic).

At one time, the MIT PDP-10 MacLisp compiler was compared to DEC's
PDP-10 Fortran compiler.  When appropriate declarations were supplied
in the Lisp code, the performance of compiled Lisp arithmetic rivaled
that of the Fortran code.  It would hardly be fair to compare Lisp
without declarations to Fortran, since the Fortran compiler would have
more information upon which it could base its optimizations. A more
recent test found that numeric code compiled with optimizations using
CMU CL is within the same ballpark as highly optimized Fortran code.
For unoptimized Fortran code, CMU CL was about 4 times faster.
Even the speed of numeric code generated by other Lisp compilers
(AKCL, Allegro, Lucid) was well within an order of magnitude of good
Fortran and C compilers (although slower than CMU CL).  Inspection of
the emitted C code from AKCL doesn't reveal many obvious sources of
inefficiency. (Since AKCL compiles Lisp into C, there are many cases
where KCL code is as fast as hand-written C code.)

See the paper peoplesparc.berkeley.edu:/pub/papers/fastlisp.ps.Z
for a discussion of the speed of Lisp vis a vis Fortran or C.

Since Lisp is a good language for rapid prototyping, it is easy for a
mediocre programmer (or even a good programmer, who isn't being careful) to
generate a large amount of inefficient Lisp code. A good example is the use
of APPEND to link successive lists together, instead of keeping a pointer
to the tail of the list. Often a programmer can obtain significant
speed increases by using a time/space profiler to identify the
functions which waste time (often small functions which are called
frequently) and rewriting those functions.