This significantly drops the overhead of deserializing
GVariant which hottest path is in
Particularly because it was nearing O(n²). When doing a simple search from
gnome-clocks we clocked in around 500,000 to 1,000,000
GWeatherLocation instances allocated and freed.
Instead, at startup, a kdtree is built using the lat/lon positions of
== GWEATHER_LOCATION_CITY along with it's index in the
World.locations of the
Not all of the
find_nearest_city() variants have been implemented because they would require an additional parameter of the allotted distance before additional filtering is applied. The most important hot path, however, is drastically reduced into a fraction of a percent of overhead according to Sysprof.
Simple testing with Sysprof shows this takes things from about 15% search time in
gnome-clocks to about 2%.
We're still easily creating 10s of thousands of
GWeatherLocation though and solving that would be how you get this into the
.25% CPU range.