Re: Executing code at compilation time

Ray <bear@sonic.net> writes:


> If I can write an O(n^2) or even O(2^n) algorithm and get O(1) runtime
> performance, I'm not going to lodge a complaint.
>
> Things get hazier in the event of O(infinity) or non-halting programs


It would be O.K., if you could rely on _every_ compiler for the language
to make these optimisations. If your own compiler optimises an O(n^2)
algorithm to O(n), you may not experience any performance issues in you
own tests, but if you ship your code to a customer who recompiles it
using his own compiler (e.g., after making a simple modification) or
your own company changes compiler, the recompiled code might well have
performance problems.


Even worse if you compiler can eliminate an infinite loop: If the
customer recompiles your code, he may get nontermination and will
(rightly) conclude that your code is bad.


So, unless you have full control of all future compilations of your
code, you should not rely on compiler-specific optimisations to achieve
the desired performance. You can be happy if the compiler does
something clever, but you should make sure that the performance is
acceptable even without fancy optimisations.


Unless these optimisations are guaranteed by the language definition.
For example, the Scheme standard mandates that tail recursion (both
direct and indirect) must use constant stack space. So you can without
worries write your code in tail-recursive style and be sure all future
compilations of your code will apply tail-call optimisation.


Alternatively, if the optimisations are done as source-to-source
transformations, you can apply these before shipping the code. The
downside is that transformed code tends to be less maintainable than the
original source.


Torben

Return to the comp.compilers page.
Search the comp.compilers archives again.