>>23
You can write fairly efficient Lisp code (aproaching C speeds) if you need to, but to do this you usually need to know your Lisp implementation to some degree(you have to declare types, so the compiler could optimize better, maybe use some internal routines, inline stuff, write compiler-macros and give the compiler other advise). It may end up cleaner than the C version, but it may also end up more complex. The general rule regarding efficiency and optimization in Lisp is that you do this:
1)Write the most clear/obvious version
2)Profile and locate bottlenecks
3)See if better algorithmic optimizations can be performed, if so, do them, and go back to 2
4)Start doing micro-optimizations if 3 failed. Type declarations, compiler-macros, other tricks. If not enough, continue to 5
5)Implementation-specific optimizations
- Use internal implementation functions
- Inline C code may be permitted by some implementations(ECL)
- Inline assembly may be permitted by some impementations(SBCL,CCL)
6)If 5 or 4 are not satisfactory, you could just write the high-performance part in asm or C and link with it using an FFI.
When your application has no bottlenecks or all its code-paths need to be micro-optimized, you're probably better off coding it in C. Lisp is also great as a prototyping language, which is much harder to say for C.
P.S.:High-performance libraries have been written in Lisp(for a quick example, search for SB-MD5) that approach C levels in speeds. They use implementation-specific tricks for achieving speed.
tl;dr: Lisp is more of a language for solving problems you don't yet now how to fully solve, or where performance isn't critical. You can achieve high-performance in Lisp, if you know your implementation well, but it's not what you usually use Lisp for. If you're writing an application whose design you fully well know, and all code-paths require maximum performance that you can squeeze, just use C or assembler.