Conversation
js/data/buffer.js
Outdated
There was a problem hiding this comment.
Sorry about undoing your work here @mourner . We need to construct attribute from scratch because it sometimes includes some extraneous non-serializable fields (namely the value property which is a function)
There was a problem hiding this comment.
Yeah, this looks good. One minor remark is that asserting itemSize should probably happen after it gets its new value.
|
I might've gotten the benchmarks wrong before. Here's what I'm seeing now: |
|
That doesn't look very good, we'll have to find a way to cut this down... |
|
Agreed. I'm working on it.
|
|
With a little bit of 😈 we can get |
|
I think we can squeeze out a little more perf by looking into
... but I'm not sure if its worth the effort / additional complexity. What are your thoughts about the latest numbers, @mourner @jfirebaugh? About the overall architecture? |
Went down this 🐰 hole for a few hours this morning and couldn't find the right arrangement to actually make this faster (while still being comprehensible to human beings). Working in this hot code is hard. Adding a single array/object allocation or function call can be VERY expensive. |
|
I feel you. :( Awesome progress though! And very very evil 😈 |
|
I understand this looks like a lot of code, but the only new logic is in The logic in the old Most other files have only changed to accommodate little differences between the |
|
Unfortunately, its a big 700-LOC 💊 to swallow and I can't identify any clean way to break this into multiple PRs. I am happy to walk anyone through the changes here over voice or answer any questions. With this PR, I feel like I can see the light at the end of the data-driven styling tunnel (partially obscured by #1336 😬) |
|
I think this is in a good place now for 👀 @jfirebaugh |
|
In future non-urgent PRs, I think it'd be nice to
|
Also moved some constructor options to SymbolBufferBuilder
|
I'd like to eventually move in the direction of b49a929 but that'll require enough refactoring (namely for |
|
I'm going to shuffle some things around in here to nudge this towards the architecture in mapbox/mapbox-gl-native#2730
I might also take this as an opportunity to recut this big PR into a couple smaller PRs. |
|
Closed re previous comment |
cc @jfirebaugh @mourner @tmcw @ansis
The overall goal of this PR is to clean up the
Bucketclasses and refactor them to lay the groundwork for per-layer buffer layouts. This PR includes the following changesBuckettoBufferBuilderBufferBuilderto cut down on boilerplate and repeated codeBufferBuildercreation (removecreateBucketmodule, remove external property initialization byWorkerTile)LayerTypeobjectsBufferSetand madeBufferBuilderresponsible for creating its own buffersBuffer::pushto accept an objectPerformance
How's performance? It's not great / not bad. I think we can improve it further.
Next Steps