Related articles |
---|
Optimization for OOP sgkelly4@gmail.com (2008-05-03) |
Re: Optimization for OOP torbenm@app-1.diku.dk (2008-05-05) |
Re: Optimization for OOP mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2008-05-05) |
Re: Optimization for OOP dot@dotat.at (Tony Finch) (2008-05-05) |
Re: Optimization for OOP lucretia9@lycos.co.uk (lucretia9@lycos.co.uk) (2008-05-05) |
Re: Optimization for OOP mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2008-05-06) |
Re: Optimization for OOP sgkelly4@gmail.com (2008-05-06) |
From: | torbenm@app-1.diku.dk (Torben =?iso-8859-1?Q?=C6gidius?= Mogensen) |
Newsgroups: | comp.compilers |
Date: | Mon, 05 May 2008 09:45:24 +0200 |
Organization: | Department of Computer Science, University of Copenhagen |
References: | 08-05-008 |
Keywords: | OOP, optimize |
Posted-Date: | 05 May 2008 11:12:01 EDT |
sgkelly4@gmail.com writes:
> I'm in the beginning of writing an optimizer for an object oriented
> programming language. At the moment I'm working on developing a list
> of possible optimizations that can be performed on the code. The
> language runs on a virtual machine.
The most important optimisation is to get rid of dynamic method calls.
This can, however, be quite tricky as you can't tell if a method can
be overridden without knowing the whole program, so it plays havoc
with separate compilation. A compromise is to allow methods to be
declared "final", which ensures it is never overridden.
If you design your own language, you can make "final" the default, so
you would have to write explicitly if a method is allowed to be
overridden. In many cases, methods are final, but the programmers are
just to lazy to declare this, or think "yeah, maybe, I will in the
future override this, so I'll just leave this possibility open", and
then they never override it anyway.
Torben
Return to the
comp.compilers page.
Search the
comp.compilers archives again.