Cleanup recalcTrack

[quaelnix]

The new code is functionally equivalent.

[afischerdev]

@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]

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]

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

[afischerdev]

@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]

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

[afischerdev]

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.