Re: [dev] Conversation with Anselm R. Garbe of

From: Alan Busby <>
Date: Wed, 16 Sep 2009 17:46:37 +0900

On Wed, Sep 16, 2009 at 5:28 PM, Anselm R Garbe <> wrote:

> 2009/9/16 Alan Busby <>:
> >
> > On Wed, Sep 16, 2009 at 4:42 PM, Anselm R Garbe
> >>
> >> IDE's like Eclipse have code assitance support to generate these
> >> automatically, great isn't it? So if you imagine a Java program where
> >> each datum access happens through getters and setters, the program
> >> must become a magnitude faster if the underlying code would be
> >> replaced using direct datum/field access instead, wouldn't it?
> >
> > No, because even in C the compiler should be smart enough to do it for
> you.
> > In Java, you can have even more convoluted code and the interpreter can
> > optimize it for you while it runs. GCC supports something similar as well
> > with -fprofile-generate and -fprofile-use .
> Of course there are various runtime optimisations presents in
> nowaday's Java VMs and even compile time optimisations in AOT byte
> code compilers, also wrt this aspect. However the downside of these
> runtime optimisations has a cost: memory and duplicated data access
> structures, that are believed to perform better. And if you imagine
> that field access happens in 90% of all Java code through
> optimised-away getter/setter calls, then this has surely an impact and
> the thesis might still prove true. I'll definately add this to my
> experiment project that does very weird stuff in Java, like very long
> inheritance chains, classes with many thousand methods/fields etc. I
> plan to do publish the experimentsat some point.

Neither of us provided enough details to argue over, but I'd like to point
1. Getters/Setters are generally caught by simple function inlining.
2. Run time optimizations can be as simple as loop unrolling, and don't
necessarily have any impact on data access structures.

Saying the above though, I agree that OO adds needless complexity in most
cases and hence I've come to avoid it. I have found closures to be very
useful though, and have not run into issues where they caused problems
relating to data access.
Received on Wed Sep 16 2009 - 08:46:37 UTC

This archive was generated by hypermail 2.2.0 : Wed Sep 16 2009 - 08:48:01 UTC