Performance improvements

[FabianTerhorst]

Instead of calculating the deltaX, deltaY and r for each item n*n times, it now calculates them n times. Also reduced the allocations by caching the transformed polymer instead of allocating it inside each interaction check.

[FabianTerhorst]

This is fixing #10 as well.

[FabianTerhorst]

TODO:

• it should be possible to cache the distance from each path to the observer to calculate that n times instead of n * n times as well
  Tested it: too much to cache not worth it.

[slvrfn]

@FabianTerhorst Check out some of the recent branches i made in my fork of the repository, I tried out a few performance improvements that didn't end up being improvements. I found Java to be faster/better at allocating many small objects that eventually get garbage collected instead of performing object pooling.

[FabianTerhorst]

What im doing there isn't the same its just calculating the values in the loop before the intersection check happens n * n times. Its not caching any values accross multiple measurements. Colors are also very easy to calculate thats why i inlined the full logic there so that its getting full java jit optimization.

[FabianTerhorst]

I added a few more raycast algorithms for testing the performance differences. Currently i would prefer the new one 4b0b326#diff-7798cc0d3e9fcdd35a27e8e0f6febf5dR85 .

[slvrfn]

Here is a place i was trying to improve but am having trouble with:

I have been doing some profiling of the library, and i found the Paint object instantiation is about 75% of the Item creation. If we can reuse the paint objects, we can save a bunch of time here.

[FabianTerhorst]

have you tried caching the paint object with the associated color integer that got calculated from android.graphics.Color.argb?