[patch] Coordinates internal improvements

[shinigami]

QuadBuckets.QBLevel is changed to static class, it allows direct creation of QBLevel[] without reflection - see getChildren().
hasChildren() result is now cached.
firstChild()/next_sibling() works without repetitive creation of array of children.
matches() has faster way for Node primitives.

[Don-vip]

Don't forget [patch] in ticket title, we have a report for them :)

[Don-vip]

In 6178/josm:

fix #9002 - QuadBuckets improvements (patch by shinigami)

[shinigami]

Oki:)

Btw. to you have stats about environments users have (memory, cores,..), dataset sizes and so?

[Don-vip]

Right now, no. The best I can give you is OS and architecture (32/64 bits) stats.

[AlfonZ]

Failed unit test ​http://donvip.fr/jenkins/view/All/job/JOSM/70/testReport/junit/org.openstreetmap.josm.data.osm/QuadBucketsTest/testRemove/

[shinigami]

hm, I runned it and it was ok, will check it again..

[shinigami]

fix

[Don-vip]

In 6181/josm:

see #9002 - fix QuadBuckets

[shinigami]

Replying to Don-vip:

Right now, no. The best I can give you is OS and architecture (32/64 bits) stats.

I asked because I made change in Node/NodeData, replacing doubles with LatLon and EastNorth instances. There were written that it was inlined because of lower memory usage, but now, when LL/NE are immutable and can be shared, overhead wouldn't be so big. In worst case (every node has uniq. LL and precounted EN) it takes ~2x more memory (2 pointers + 2 objects), which makes ~30MB memory on 1M nodes, so nothing fatal.. In best case (node without or shared LL/EN) it takes 1/4 (just two pointers).

Other plus is, it removes loots of creations of new LatLon/EastNorth objects;).

[shinigami]

here is patch;)

[Don-vip]

I think we are more often in the worst case rather than best or even intermediate state.

[anonymous]

But still it is not so much memory and it saves lots of operations. Similar problem is with BBox and Bounds.

Other problem is nearly no one caches return val of getCoor(), its common to use it as if (n.getCoor()!=null){n.getCoor().lat().. n.getCoor().lon()...} and similar "effective" constructs.

[bastiK]

Yes, it is much memory. As the number of Node instances scales with the size of the dataset, this is exactly the place where memory optimization is important. You can open files of several hundred MB in JOSM, so it adds up.

Basically you are reverting [4126] which I think was a nice optimization.

Can we close this ticket?

[shinigami]

Not exactly, need not make defensive copies now, so it saves short living mess and allow share objects.
But you are right, I tried it and it consumes about 25% more memory (it makes 0.5GB for all Norway - 2.34GB osm file). Understand that not everyone has 32gigs yet:).