Optimizing code may introduce bugs to software that runs perfectly when non-optimized.
Also, the level of performance gain depends highly on the internal structure of the source code. AutoLISP is a language in which you can easily write programs that create or modify functions at runtime. This use of the language by definition contradicts compile-time optimization.
The Visual LISP compiler analyzes the code it compiles and links, then it creates a report pointing you to all source code segments that may cause problems when optimized. If you do not receive any optimization warning messages, you can assume optimization did not introduce new problems to your code.
The compiler is able to detect most problematic situations in AutoLISP code. However, there are situations in which it is impossible to detect code that may become incorrect during the optimization. If your program uses one of the following constructs, the compiler will not be able to prove correctness of the optimized code definitively:
- Interaction with external ObjectARX and Managed .NET applications that set or retrieve AutoLISP variables
- Dynamic calls to functions defined by ObjectARX and Managed .NET applications
- Evaluation of dynamically built code using eval, apply, mapcar, or load
- Use of set to set dynamically supplied variables
- Dynamic (program evaluated) action strings in action_tile and new_dialog
Remember that any optimization will change program semantics. The compiler intends to preserve the behavior of project components relative to one another. The compiler cannot guarantee unchanged behavior between your project and external procedures. Typical effects of optimization include the following:
- Outer applications and the Visual LISP Console window lose access to program functions and symbols.
- Functions available from the Visual LISP Console window in interpreter mode are unknown in compiled mode.
- Functions are available from the Visual LISP Console window, but redefining them does not change the program's behavior.