3 optimizations (especially eliminating double-calculation of traffic distance between traffic cache and audible alerts)

[shanelenagh]

Doing some inspection and CPU flame chart analysis of AvareX while traffic was on, I found 3 opportunities for optimization, which are addressed with this PR (the third of which doesn't deal with traffic per se, but it was something I noticed in the chart while looking at the others):

1. Traffic distance was being computed twice, once by the traffic cache in the sort method for limiting the display (and consequently audible alerts) to the "top 20" traffic items, and then again by the audible alerts itself. I instead changed the traffic cache to do the computation once on each traffic instantiation (and then again for all traffic in the cache when ownship changes position, which would affect the prior computation for all traffic, of course), and persist that on fields on the traffic object. That is then used by the audible alerts, which no longer needs to do it itself. Also, as part of this, I made the algorithm for the computation use the Haversine formula (what AA was using), which is within 0.3% (3/10 of a percent) of the Vicenty formula for accuracy, but is much, much faster (CPU flame chart analysis bore this out). And I am using the same library, LatLong, for that, as they allow you to select either Vicenty or Haversine in the constructor. I think Vicenty makes sense in the rest of the app where high precision for less frequent calculations might be a higher concern, but when it is computing it for every traffic item often many times per second (per ADSB updates) Haversine makes more sense.
2. Changed audible alerts calls to not step on themselves. Both the flame chart and some debugging showed the AA feature being called ridiculously frequently (every single traffic item insert) and processing every traffic item again when there were no changes. Yes, I had code in there to exit when there was no updated timestamp, but even the multiple iterations through the cache and the hashmap check were showing up in the chart. Now it calls the AA processing loop no more frequently than once every 100 milliseconds, which is plenty frequently still.
3. There was a dateformat that was showing up on the flame chart in the Instruments code. I had just watched a video from the Google Flutter team on performance optimization where they used this exact thing as an example (https://youtu.be/vVg9It7cOfY?si=WcUmLXwQc66nQOM-&t=2386), so I knew the simple solution--make that format (which has no per-instance unique properties) a static of the class. That removed it from the prominent space it was taking on the chart.

I can provide some screenshots (say of the before/after flamecharts) and screencast demo's if required; let me know. They did have a demonstrable impact when I ran them on my device (my screaming G16 laptop with the RTX 3070 Ti didn't care, of course, but that isn't what I will be flying with :-)

[shanelenagh]

Zubair, I was wrong, there were no merge conflicts even after you merged in the other PR--Git never ceases to amaze me with how well is does these things! So you can merge this whenever you feel comfortable, @apps4av, as there is no need for me to rebase and resolve conflicts (there are none, from what I see and what Github is saying here).