Hi Gerd,
I think there are some steps left for the optimization. Therefore I have
created a new branch (performance) for all kind of performance
improvements (starting with your LocationHook optimizations). It's
easier for other people to test.
The branch can be merge back to the trunk if it reaches stability.
One new idea:
I think your idea to use the first point of a way to get it's location
information is better than the old behaviour of the LocationHook because
that was not forseeable. Now we have an easy rule: First point (or if
that has no location information the next point which has such information).
What do you think about using the mid point instead of the first point.
The mid point (points.size()/2) would avoid problems with streets that
have one point just before the city border. Using the mid point would
give a higher probability that most (or all) of the street lies in the
same boundaries like the mid point.
WanMil
> Hi,
>
> this contains the corrections and optimizations suggested by WanMil and is
> now based on r2168.
> I decided to return a reference to the internal Tags instance instead of
> using a costly Tags.copy() for each result of quadtree.get()
> If that is not liked, I suppose to change the get() to something like
> addLocationTags (Coord co, Tags tags){..}
> to let quadtree add the missing tags to the callers tags strucure.
>
> ciao,
> Gerd
>
> http://gis.638310.n2.nabble.com/file/n7182307/locationHook_speedup_v4.patch
> locationHook_speedup_v4.patch
>
>
>
> --
> View this message in context:
> http://gis.638310.n2.nabble.com/Patch-v4-LocationHook-with-new-Quadtree-tp7182307p7182307.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list
> [email protected]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
