search

abrensch / brouter

configurable OSM offline router with elevation awareness, Java + Android
MIT License
490 stars 118 forks source link

Cleanup recalcTrack #535

Closed quaelnix closed 1 year ago

quaelnix commented 1 year ago

The new code is functionally equivalent.

afischerdev commented 1 year ago

@quaelnix Thanks for the cleaning idea.

But I'm not sure if I agree with it. Beautifying readability is only one part. The variable integers are allocated, filled, used and freed in each iteration of the loop. So I prefer to allocate the variables before loop. This may be old school. I'm not sure if the modern compilers adjust this out.

quaelnix commented 1 year ago

I'm not sure if the modern compilers adjust this out.

Even if they would not optimize stuff like this (which they do) the performance difference would be small enough that it does not justify a 3x increase in lines of code, which makes it a lot harder to understand what is going on than necessary.

Beautifying readability is only one part.

This cleanup was a byproduct from back in the time when I was double checking what this function actually does. Feel free to close the pull request if you dislike the changes.

quaelnix commented 1 year ago

For reference: https://source.android.com/docs/setup/contribute/code-style#limit-variable-scope

afischerdev commented 1 year ago

@quaelnix Thanks for the link.

I didn't mean the for (int i = 0; ...) variant. So I did a small java test and compiled it to byte code (javap -c).

Routine with variable declaration inside the loop is two instructions shorter. Interesting thing.

TestLoop.java.txt TestLoop.byte.txt

quaelnix commented 1 year ago

Keeping the scope of the variables small also makes the life of the optimizer easier.

afischerdev commented 1 year ago

It works for generic variables. But I'm still not sure about Java classes. The overhead of allocating and deallocating within a loop can vary by class. E.g. OnDraw complains regularly when I declare new classes within.