Pack Geometries before passing to a web worker #2342
Conversation
…eometries packable.
…implement packable.
…lement the packable interface.
…Also added packable tests for box, circle and ellipse fill/outline geometries.
…utline geometries.
… worker support to unpack the geometry.
…orker. Unpack when necessary of the web worker.
| }); | ||
| if (defined(geometry.constructor.pack)) { | ||
| var packedLength = defined(geometry.constructor.packedLength) ? geometry.constructor.packedLength : geometry.packedLength; | ||
| var array = new Float64Array(packedLength); |
There was a problem hiding this comment.
I need to dive into this a bit; but I suspect in order to see any real performance increase we'll need to refactor this code that we only create numberOfCreationWorkers typed arrays instead of creating a typed array per sub-task. Currently, it looks like we are subdividing the tasks after creating a single array, rather than figure out how many should go in each task and doing it up front.
This problem is starting to come back to me now that I'm looking at it; in addition to packing I think we need to overhaul the way the creation tasks are sent to the worker as well. The overhead of creating a promise and task per geometry is probably larger than we need it to be. I don't know how familiar you are with all of the worker stuff, but I can dive into this over the holidays on my own branch and then PR into this one.
|
Do we want this for 1.5? If so, we should aim to merge this today. |
|
Definitely not for 1.5. |
Pack geometry creation sub-tasks
| geometry = subTask.geometry; | ||
| if (defined(geometry.constructor.pack)) { | ||
| subTask.offset = packedLength; | ||
| packedLength += defined(geometry.constructor.packedLength) ? geometry.constructor.packedLength : geometry.packedLength; |
There was a problem hiding this comment.
I would change this to defaultValue(geometry.packedLength, geometry.constructor.packedLength);
|
I did a quick once over since I know you said you had more work you wanted to do in here. So far it looks great, this will be a significant performance improvement for loading large amounts of asynchronous geometry. Let me know when you're done and I'll give it a more complete pass. |
…, ellipse, sphere, and ellipsoid fill/outline geometries.
…ylinder, polygon, polyline, polyline volume, rectangle, and wall fill/outline geometries.
…ackable and have a createGeometry function.
|
@mramato This is ready for review. |
| @@ -731,8 +731,14 @@ define([ | |||
| for (i = 0; i < length; ++i) { | |||
| geometry = instances[i].geometry; | |||
| instanceIds.push(instances[i].id); | |||
|
|
|||
| var moduleName = geometry.constructor.name; | |||
| if (moduleName === "Object") { | |||
There was a problem hiding this comment.
Is this to handle pre-created geometry?
|
Did we have performance stats for this? |
|
This is a break change for folks implementing their own |
|
@bagnell actually has to back out his last commit, which turns this into a non-breaking change. Even with the latest commit, it only changes the private API. It's currently impossible to implement an asynchronous geometry with the public api (with or without this change). |
…lement packable and have a createGeometry function." This reverts commit 4073f38.
The stats were posted in #2365. |
Thanks. |
|
In Chrome, an average of 5 runs loading |
|
I've played with this enough that I'm happy bringing it into master (plus it will have plenty of time to stew before the next release). Despite the size of the PR, it's actually not that big of a change (lots of boilerplate code for pack/unpack). I'll update CHANGES and merge. |
Pack Geometries before passing to a web worker
I'm opening this PR early so @mramato can take a look. I'll post performance numbers soon.