Re: Optimization for OOP

Thanks for the responses!


Anyway, the final Idea is good, it will allow me some more knowledge
about what the programmer feels a function should be doing. And thus
allow the optimizer to know what it can do. However, the problem is,
because of the way the optimizer is set up (basically the way in which
it sits between the compiler and executer, something which I have no
control over) I can only analyze one source file at a time, and can
NOT keep track of information from file to file. Obviously this is a
huge disadvantage for optimization, but its all that I can do.


Some of the stuff I was considering for objects is as follows:
1) perform checking of interfaces at optimization time and prevent
this from needing to happen at execution time IF the interface is in
the same file. (otherwise it is outside the scope I can work on and it
is possible that the interface may be different from compiling to
compiling)
2) perform inlining of small private methods and of small final
methods
3) convert small get/set type functions for private data members into
direct accesses of the data members


Unfortunately the way in which OOP is implemented in the language
makes it nearly impossible for me to put any good optimizations in at
compile time as its fairly unlikely that the optimizer will know much
if anything substantial about a class at compile time. I suppose it
may be possible to write a heavy weight compile time optimizer and a
VERY light weight execution time that attempts to quickly make pre-
targeted replacements and optimizations if appropriate. However, an
execution time optimizer is a slippery slope since there is a good
chance if the optimizations are good and done quickly then it could
actually slow down the execution.


Another model which I have been considering is the use of a profiler
based optimization system. In which I could embed a profiler into the
VM, the profiler could attempt to detect bottle necks and in order to
improve OOP try to figure out the cases that classes *usually* resolve
to (i.e figure out if class A in file a always makes use of abstract
class B in file b). This information could then either be used by a
compile time optimizer to re-optimize the code OR by an execution time
optimizer to better target areas of highest execution time
optimization in order to keep the execution time optimizer costs to a
minimum. Obviously, the profiler should try to turn itself off at some
point (or allow the user to turn it off) in order to attempt for a
zero or close to zero impact from the hooks to the profiler. In other
words... collect data for a while, either re-optimize with profiler
data or build better execution time optimizer targets, and then shut
the profiler down in order to make further execution even faster. It
should be noted that the optimized code would be saved for possibly
thousands of executions, therefore... it may make sense to put a
performance hit on say the first 100 executions in order to detect how
the next 1000+ executions could be done better and faster.


This of course is all speculative and the actual implementation is
probably not in the near future. At the moment I'm just finishing up
the peephole optimizations, and I plan on tackling areas such as loops
long before I tackle complex OOP optimizations (though, hopefully they
should show a good deal of improvement for execution).


Anyway, this post really just turned into a brain dump of where I am
with the OOP optimization stuff right now.

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