Possible performance improvement with downloads?

[GerdP]

I've noticed a few cases where the processing of downloaded osm data consumes a lot of CPU time, esp. with the MultiFetchServerObjectReader. I think the reason is that we store packages of primitives in DataSet instances. Class DataSet maintains a spatial index. For this index the bounding box of ways and relations is computed and - in some cases - recomputed frequently while more data is downloaded and merged. If I got that right some actions would be much faster if we could avoid to maintain the index and the bounding boxes until the data is finally rendered.

My idea is to change class DataSet to fill the spatial index only when it is used. Work in progress...

[GerdP]

I think 20658.patch​ is all that is needed.
There is one side effect that might cause side effects:
The unpatched code always calls method OsmPrimitive.updatePosition() when the object is added to the dataset, the patched version only does that when the index is build. I have to find out if this causes problems.

If not I'll probably commit this after the release of the next version.

[GerdP]

Looked at this again and cannot reproduce the problem with downloads. Probably circumvented with simpler change in r17635.
The patch might still be useful if this situation is created somewhere else.

[skyper]

Downloading a complete relation might work now, but did you try to update a data layer with hundreds or more relations? I still have problems with that.

[GerdP]

Did you try if the patch solves your problems?

[skyper]

No, sorry, I have no compile system set up. Rereading your patch and the comments, I rather think it will not solve it, as it is only for rendering but my problem is with computing the list of needed downloads of objects with a lot of relations.

I am sorry for the noise.

[GerdP]

You probably mean "a lot of relations" but no download area. In this case lots of (all) objects are updated.
I assume that r17635 improved this for the download phase, esp. when lots of nodes are downloaded.

[skyper]

r17365 or r17635?
Have not noticed a real improvement but I have to recheck. Yes, I have a lots of route relation (100+), mostly incomplete, and some ways (500-5000). All or most of it outside download area.

[GerdP]

Sorry, yes, r17635. I've corrected the typo above. If there is a download area you should not see performance problems unless you have many small or some huge ones, as in this case the "Update data" simply downloads the areas again.
Maybe you meant "Update modified"?