Note that there are some explanatory texts on larger screens.

plurals
  1. POAre public getters and setters fine for Android if made final? Is final-correctness as important in Java as const-correctness is in C++?
    primarykey
    data
    text
    <p>I was reading this: <a href="http://developer.android.com/training/articles/perf-tips.html" rel="nofollow noreferrer">http://developer.android.com/training/articles/perf-tips.html</a></p> <p>Particularly this about internal getters and setters:</p> <blockquote> <p>Virtual method calls are expensive, much more so than instance field lookups. It's reasonable to follow common object-oriented programming practices and have getters and setters in the public interface, but within a class you should always access fields directly.</p> <p>Without a JIT, direct field access is about 3x faster than invoking a trivial getter. With the JIT (where direct field access is as cheap as accessing a local), direct field access is about 7x faster than invoking a trivial getter.</p> </blockquote> <p>It mentions "virtual method calls" which, probably, also refer to public methods. I have a bunch of methods in my class where the methods shouldn't be overridden. For example:</p> <pre><code>public class Something { private float m_Float = 0.0f; public float getFloat () { return m_Float; } } </code></pre> <p>I always want 'getFloat()' to return 'm_Float', even in derived classes. Does marking the method 'final' improve performance for Android devices? Even if it doesn't, is final-correctness as important as const-correctness? Like, do Java programmers get anal when fellow colleagues forget about final-correctness?</p> <p>If marking the method <code>final</code> improves performance, is the performance gain nullified for the following?</p> <pre><code>public class Base { public int getRandomNumber () { return 4; //chosen by fair dice roll. //guaranteed to be random. } } public class Derived extends Base { public final int getRandomNumber () { return 6; //chosen by second fair dice roll. //guaranteed to be more random. } } </code></pre> <p>I'm not really interested in optimizing my code at this point but I am interested in the final-correctness bit.. I'm not familiar with the standard conventions where Java's concerned.</p> <p>[EDIT]</p> <p>Okay, so, above, this link is given as a possible answer: <a href="https://stackoverflow.com/questions/6716442/android-performance-avoid-internal-getters-setters">Android Performance - &#39;Avoid Internal Getters/Setters&#39;</a></p> <p>The reply marked as the answer links to this: <a href="https://stackoverflow.com/questions/4912695/what-optimizations-can-i-expect-from-dalvik-and-the-android-toolchain/4930538#4930538">What optimizations can I expect from Dalvik and the Android toolchain?</a></p> <p>It seems that simple getters and setters are inlined now.</p> <blockquote> <p>In Gingerbread we added simple inlining for getters/setters. Since the underlying JIT frontend is still simple trace based, if the callee has branches in there it won't be inlined. But the inline cache mechanism is implemented so that virtual getters/setters can be inlined without problems.</p> </blockquote> <p>And in the comments, this is asked:</p> <blockquote> <p>(3) Should I declare my methods final wherever possible? Or does that still count as a virtual callsite?</p> </blockquote> <p>And this is the reply:</p> <blockquote> <p>(3) Yes please</p> </blockquote> <p>So, with the comments here and whatnot, I'd say everything's resolved. (Except for when <code>final</code> should be used with methods; but that will probably be answered very soon. I have a belief but am waiting for it to get validated or refuted with a reason, so..)</p> <p>[EDIT]</p> <p>Also, doesn't this mean that the Android docs. about performance tips is.. outdated?</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COFinal in front of a method declaration just means you can't override it. It's a compile time check. They're talking about calling a method vs. accessing the variable directly. That said ... rarely does anyone need that optimization and there are plenty of *design reasons* for calling a getter rather than accessing the variable. And no, there's no real concept of "const correctness" in Java for the most part.
      singulars
    2. CO@BrianRoach Yeah, when I read that we 'should always access fields directly' internally, I cringed. I like the flexibility and occasional safety checks I can put into getters and setters. So.. Does that mean that a method marked final is **still** a virtual method? I know that const-correctness is not the same as "final-correctness", if I may call it that, but is it important? Like, "Get it right or God help me I'll murder you with an axe" important?
      singulars
    3. COCorrect. All methods are loaded at runtime by the classloader. The JIT can make improvements by inlining things but it figures that out for itself.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload