performance profiling on the 'doubles' branch

[spyhunter99]

PR #48 has been integrated into the branch 'doubles'. This should hopefully provide better accuracy when setting the map extents and when plotting points. Since this is a large change, I'd love for someone to run some kind of performance impact analysis on this to find out if it's worth it or not.

It may actually be better to do the same type of branch with floats as the accuracy of floats may be good enough

and i don't want to do it ;)

maybe @ZKjellberg will take on the challenge!

[ZKjellberg]

What type of performance analysis would you be looking to test? Android Studio has a lot of nice tools for testing performance. Would this be mostly a memory related issue? If so, the Memory Monitor could be an easy way for a quick glimpse of the impact. I would expect a sample such as the Military Icons fragment sample would be a good test?

(NOTE: Their direction to use the Memory Monitor refers to a non-existant Tools/Android option. I suggest clicking on the 6: Android Monitor window in the bottom left corner and selecting the Memory tab. If you see 'No Debuggable Application', access Tools/Android/Enable ADB Integration. This is a common problem if you have multiple Android Studio sessions.)

[ZKjellberg]

Here are some images from the Memory Monitor with a comparison between master & doubles. You can also see CPU & GPU performance with the tool if desired.

[spyhunter99]

perfect. so we're looking at at least an extra 10 megs of ram. that's not
too terrible

On Thu, Jan 7, 2016 at 4:35 AM, Zachary Kjellberg notifications@github.com
wrote:

Here are some images from the Memory Monitor with a comparison between
master & doubles http://imgur.com/a/DPor4. You can also see CPU & GPU
performance with the tool if desired.

—
Reply to this email directly or view it on GitHub
#237 (comment).

[spyhunter99]

i guess the work from here is whether or not we find a way to reduce the memory foot print. 10MB seems a bit high IMO. A double is 8 bytes, integer is 4 bytes. That means we had at least 10MB's worth of integers previously, which is 2.5 million ints. Again, it seems high

[kjeremy]

@spyhunter99 Looking at the screenshot it looks to only be an increase of 3-4MB.