#20658 closed enhancement (wontfix)
Possible performance improvement with downloads?
Reported by: | GerdP | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core | Version: | |
Keywords: | performance download | Cc: | Don-vip, stoecker, simon04 |
Description
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...
Attachments (1)
Change History (9)
by , 4 years ago
Attachment: | 20658.patch added |
---|
comment:1 by , 4 years ago
Cc: | added |
---|
comment:2 by , 3 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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.
comment:3 by , 3 years ago
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.
comment:5 by , 3 years ago
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.
comment:6 by , 3 years ago
You probably mean "a lot of relations" but no download area. In this case lots of (all) objects are updated.
I assume that r17365 improved this for the download phase, esp. when lots of nodes are downloaded.
comment:7 by , 3 years ago
comment:8 by , 3 years ago
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"?
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.