-
Notifications
You must be signed in to change notification settings - Fork 4
Browse page performance #454
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
Comments
dabreegster
added a commit
that referenced
this issue
Jan 29, 2024
When we update filters, we're modifying a per-feature property, which forces maplibre to reprocess all the GJ data. I tried using feature state, but:
So...
|
|
Oh yeah, and
|
dabreegster
added a commit
that referenced
this issue
Jan 30, 2024
dabreegster
added a commit
that referenced
this issue
Jan 30, 2024
Also tried out updateData; it'll get us a little bit of a win, but I have to make sure line endpoints have unique IDs. https://osmus.slack.com/archives/C01G3D28DAB/p1706714321758859 for notes / benchmark results |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Loading 18MB of scheme data and filtering is still reasonably fast (a few seconds), but lag is noticeable. I did a little bit of profiling and have some ideas for improvements. I don't think any of this is important to do yet, but wanted to record these notes somewhere.
addLineStringEndpoints
takes 650-850ms. We're making a full defensive deep-copy unnecessarily, could improve this.addLineStringEndpoints
is called twice when loading a file, because we lazily instantiate theFilters
component, and becausefiltersUpdated
gets called once upon creation.The text was updated successfully, but these errors were encountered: