On Sat, 2009-10-31 at 16:28 +0100, Jiri Klement wrote: > To summarize, I would like to do following: > 1) Replace public QuadBuckets<Node> nodes in Dataset with > Collection<Node> getNodes(), that will return > Collections.unmodifiableCollection of nodes
That's fine with me, as long as you also add a few search functions to the DataSet to replace the ones that are already in use. I think that's the validator and the selection code. > 2) Replace for now QuadBuckets in Dataset with class more suitable for > iterating and looking for ids - Storage* class from josm-ng looks like > a good candidate. QuadBuckets can be used again when it makes sense > (maybe both Storage and QuadBuckets can be used at the same time, as > each class is useful for differrent type of operations) > > Are there any complains? I'm biased, but I'd really like to keep it, please. I'm using it in at least two places I mentioned above. I just committed code to the validator's UnconnectedWays test that takes a test from 3 minutes on a large data set down to less than 2 seconds. It took processing mouse clicks on the same data set from taking over a second to being instantaneous. There are certainly operations for which it is not optimal. But, as its search capabilities grow more widely, we will have less and less need to iterate over the data set. We can also tune things like the bucket size to ensure that iterations get cheaper. If you want a cheaper-to-iterate data structure, I have a suggestion. Instead of actually storing OsmPrimitives in QuadBuckets, we have an ArrayList or TreeSet sorted on id. We store the id in the QuadBuckets leaves. The lookup by id is actually a pretty rare operation in my experience. I haven't seen it show up in any performance profiles, and I've done a tone of those. -- Dave _______________________________________________ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
