27 ms·

It's sometimes difficult to fix performance issues in your app unless you know what's causing the slow-down in the interpreter, but that's usually a pain. Lisp

It's sometimes difficult to fix performance issues in your app unless you know what's causing the slow-down in the interpreter, but that's usually a pain. Lisp is a constructive language, so a lot of time is spent doing memory allocation. Interpreters often optimize that by pre-allocation and such, but to diagnose that you need to know exactly when memory is allocated, etc.. AN example: I was using the python heap module to implement a priority queue with several hundred thousand values. The memory allocation caused by the dynamic growth of the list was crippling the performance. I re-implemented it as a binary heap in C, and it was asymptotically faster.

ecuzzillo 19y ago
Lisp is compiled, not interpreted, most of the time. No one uses interpreted Lisp in production; it's all compiled. And it's compiled to very fast code, much of the time, particularly when you add type declarations.
shiro 19y ago
You're half right. Tuned Lisp code can be as fast as C, but you have to know the compiler so intimately that you can tell what kind of machine insturctions it is generating; you'll use "disassemble" a lot ("disassemble" is a part of CommonLisp standard---you may get a sense how Lispers are performance freak). Usually the bottleneck part is tuned to the point that it won't do any allocation and run-time type dispatch at all. There's one big advantage of using Lisp over C for performance: Macros. During optimization it is typical that you have to write several versions of code, changing bits and pieces, and run benchmarks to see what is optimal. Macros allow you to generate different versions of code from simple changes of parameters, without incurring overhead of function call/variable reference etc. (You can do similar thing in C++ templates, but Lisp macros allows much more). If you can easily parameterize your code, you can try more ideas and run more benchmarks, so it is more likely that you'll find better optimization. AN example: Allegro CL version 7 and later has Perl-compatible regular expression library, purely written in Lisp, that runs faster than Perl (at least at the moment I wrote it, using benchmark suite came with PCRE).

ecuzzillo 19y ago

Lisp is compiled, not interpreted, most of the time. No one uses interpreted Lisp in production; it's all compiled. And it's compiled to very fast code, much of the time, particularly when you add type declarations.

shiro 19y ago

You're half right. Tuned Lisp code can be as fast as C, but you have to know the compiler so intimately that you can tell what kind of machine insturctions it is generating; you'll use "disassemble" a lot ("disassemble" is a part of CommonLisp standard---you may get a sense how Lispers are performance freak). Usually the bottleneck part is tuned to the point that it won't do any allocation and run-time type dispatch at all. There's one big advantage of using Lisp over C for performance: Macros. During optimization it is typical that you have to write several versions of code, changing bits and pieces, and run benchmarks to see what is optimal. Macros allow you to generate different versions of code from simple changes of parameters, without incurring overhead of function call/variable reference etc. (You can do similar thing in C++ templates, but Lisp macros allows much more). If you can easily parameterize your code, you can try more ideas and run more benchmarks, so it is more likely that you'll find better optimization. AN example: Allegro CL version 7 and later has Perl-compatible regular expression library, purely written in Lisp, that runs faster than Perl (at least at the moment I wrote it, using benchmark suite came with PCRE).