Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance profiling results #29

Open
brnkhy opened this issue Mar 29, 2017 · 4 comments
Open

Performance profiling results #29

brnkhy opened this issue Mar 29, 2017 · 4 comments

Comments

@brnkhy
Copy link

brnkhy commented Mar 29, 2017

I was testing my own changes&performance and decided to share this as well.

2017-03-30_00-16-04

This frame took 981ms GetFeature takes 153 of that. Few things to note;

  • First of all, I thought we were using clipper for 16+ levels. It seems like it's working at 16 as well? Do we need it at 16- levels?
  • Yes it's mostly clipper but still there are bunch of easy improvements for slow days
  • Where & Select, or let's say linq in general, little slow and makes probably unnecessary allocations
  • List size changes are actually costly, I haven't checked this one but at my side, I started calculating the size and creating them with that size which saved me from all those array copying.
  • ToList is extremely slow. And it's even following a select statement (for tags). Is ConvertAll slower? (I couldn't re-test as profiler is actually quite slow in deep-profile mode)

I'll post if I can find anything else!

cc @BergWerkGIS

@wilhelmberg
Copy link
Contributor

First of all, I thought we were using clipper for 16+ levels. It seems like it's working at 16 as well?

No, usage of clipper is based on the buffer parameter passed to eg GetFeature() or ToGeoJson().

Passing any not-null value triggers clipper.
We currently pass 0.

Do we need it at 16- levels?

Yes, with the current implementation of the mapbox-unity-sdk (no feature filtering or feature de-duping across tile borders) it is needed to prevent duplicates features.

All vector tiles z0 -> zMax contain data that extends beyond the actual tile borders.


You could speed things up a bit (10-30% depending on the data of the vt) by passing validate = false here or here.

With validate = false some extensive checks if the tile itself and its data is valid are skipped.

@brnkhy
Copy link
Author

brnkhy commented Mar 30, 2017

@BergWerkGIS is mapbox data always valid?

@wilhelmberg
Copy link
Contributor

@brnkhy

is mapbox data always valid?

😄 yes it should always be valid.
I've enabled the validate flag as default mainly for data from other sources that users known what's going and don't think the this library is faulty.

@brnkhy
Copy link
Author

brnkhy commented Mar 30, 2017

@BergWerkGIS ah I see, it's good to know though as it's small but yet another point of perf improvement when someone asks. I know these are quite small compared to mesh gen performance issues but still it's good to keep track ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants