I recall skimming thru ACL a while back and not finding anything unusual in the ‘optimization’ chapter… unusual in terms of advice or things I did not already know or appreciate. But PAIP… I’ve never checked out. I hopefully will be able to soon. Thanks much, Gary!

Compiled CL code can definitely keep up with compiled C/C++ code IF YOU OPTIMIZE CORRECTLY. The biggest reason that CL keeps this stigma for being slow is because the language makes it easy for you to write relatively inefficient (albeit very elegant) solutions quickly. The problem is that many Lisp programmers then stop with this version of their program.

The flexibility and robustness gained by manifest typing, implicitly polymorphic functions, and automatic memory management have to be traded for some overhead in terms of CPU cycles and memory usage.

HOWEVER – and this is the big however -, where you are pretty much stuck with this situation in languages such as Perl/Python/Ruby/etc, in CL you can add type declarations, use type-specific and destructive functions, and even manage your memory explicitly to gain back all the speed and space benefits that C/C++ gets.

The really key piece to remember though is code profiling. I cannot stress this enough. All CL implementations come with some suite of profiling tools, and by running these on your initial elegant/functional solution, you can find exactly which functions are the runtime bottlenecks in your code. You then step into those functions and make the changes I mentioned above. Remember that “Premature optimization is the root of all evil” and 90% of a program’s runtime is typically localized in 10% of the code.

So good luck with the imaging library, Jake (I’m doing some similar stuff myself), and Harry, check out the chapters on optimization in both Graham’s ANSI Common Lisp and Norvig’s Paradigms of Artificial Intelligence Programming.

Now I know very little CL as I write this, but I somehow somewhat unscientifically suspect that even compiled CL code may not be able to beat its imperative, side-effect ridden C/C++ counterpart. Even with my little exposure to CL, I will give CL very high marks for its elegance, completeness, and the code writing techniques it makes possible (via macros, lambdas, and any and all FP-style enabling facilities) but I’m not so convinced if it can generate the same type of speed-efficient object code as C/C++. Would like to hear more on this from you / others.

The second example has stronger encapsulation, as it doesn’t expose a needless variable into the scope of the enclosing function/method.

I always try and minimize state in my objects, which is especially important if you need to write concurrent code. Any state left, should if possible be made immutable.

Reducing the scope of variables, and removing them altogether (where possible) is often a great way to improve code.

Learning functional languages can definitely make the nature of these improvements clearer.

Methinks you might want to take a tour through the algorithm header. Seems like learning C++ would teach you the same things learning Lisp would.

As an added bonus, often when I realize I’ve used some pattern at least twice, I find there are several other places I could use the newly created pattern to condense and simplify code in ways I didn’t originally consider. It’s a wonderful feeling.