Merge from the multipolygon branch.
Version 1195 was commited by steve on 2009-09-14 21:15:02 +0100 (Mon, 14 Sep 2009) Merge from the multipolygon branch. This does not include the code to generate sea polygons as that requires 1.6 and so will require a bit of preparation.
Hi Steve, - private final void incArcCount(Map<Coord, Integer> map, Coord p, int inc) { + private void incArcCount(Map<Coord, Integer> map, Coord p, int inc) { Why zap the final? It was there for a reason. Cheers, Mark
Steve,
Why zap the final? It was there for a reason.
And what would that reason be?
It explicitly declares that the method can never be redefined and therefore is a candidate for inline expansion. Obviously, the method is implicitly final anyway due to it being private but adding the final means that if the method is ever made non-private it will still be capable of being optimised. That's my reason, what's yours? Cheers, Mark
As far as I'm aware, declaring a method final doesn't make a whole lot of difference to hotspot these days. Hotspot can still inline a method if it's not declared final but determines at runtime it's not overriden elsewhere. If some new code eventually turns up that does override the method, hotspot will 'uninline' the method dynamically. http://www.java2s.com/Article/Java/JVM/The_Java_HotSpot_Performance_Engine_M... The only real reason that I'm aware of for declaring a method final is to deliberately prevent it from being overridden as a design decision. Chris
Why zap the final? It was there for a reason.
And what would that reason be?
MB> It explicitly declares that the method can never be redefined and MB> therefore is a candidate for inline expansion. MB> MB> Obviously, the method is implicitly final anyway due to it being MB> private but adding the final means that if the method is ever made MB> non-private it will still be capable of being optimised. MB> MB> That's my reason, what's yours? MB> MB> Cheers, MB> MB> Mark
Hi Chris,
As far as I'm aware, declaring a method final doesn't make a whole lot of difference to hotspot these days. Hotspot can still inline a method if it's not declared final but determines at runtime it's not overriden elsewhere. If some new code eventually turns up that does override the method, hotspot will 'uninline' the method dynamically.
http://www.java2s.com/Article/Java/JVM/The_Java_HotSpot_Performance_Engine_M...
The only real reason that I'm aware of for declaring a method final is to deliberately prevent it from being overridden as a design decision.
That's very interesting, I didn't know that the Java runtime was as sophisticated as that. So, indeed the final was not actually doing anything useful apart from expressing my intention. No doubt, that's why Steve removed it. Cheers, Mark
On 15/09/09 08:34, Mark Burton wrote:
That's very interesting, I didn't know that the Java runtime was as sophisticated as that. So, indeed the final was not actually doing anything useful apart from expressing my intention. No doubt, that's why Steve removed it.
Yes even although the advice to use final is frequently seen on the internet 'for performance' it is not really true. And if it were you would be better to make the class final anyway. Cheers, ..Steve
participants (4)
-
Chris Miller -
Mark Burton -
Steve Ratcliffe -
svn commit