Modify

Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#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)

20658.patch (5.1 KB ) - added by GerdP 4 years ago.

Download all attachments as: .zip

Change History (9)

by GerdP, 4 years ago

Attachment: 20658.patch added

comment:1 by GerdP, 4 years ago

Cc: Don-vip stoecker simon04 added

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.

comment:2 by GerdP, 3 years ago

Resolution: wontfix
Status: newclosed

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 skyper, 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:4 by GerdP, 3 years ago

Did you try if the patch solves your problems?

comment:5 by skyper, 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.

Last edited 3 years ago by skyper (previous) (diff)

comment:6 by GerdP, 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.

Version 1, edited 3 years ago by GerdP (previous) (next) (diff)

comment:7 by skyper, 3 years ago

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.

comment:8 by GerdP, 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"?

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.