Worker transfer benchmark #7145
Conversation
bench/benchmarks/layout.js
Outdated
| }); | ||
| } | ||
|
|
||
| bench(getGlyphs: Function = (params, callback) => callback(null, this.glyphs[JSON.stringify(params)]), | ||
| getImages: Function = (params, callback) => callback(null, this.icons[JSON.stringify(params)])) { | ||
| parseTiles(loadImages: Function, loadGlyphs: Function) { |
There was a problem hiding this comment.
Rather than using inheritance for code reuse, could we pull parseTiles out into a module in bench/lib that is used by Layout and WorkerTransfer?
There was a problem hiding this comment.
We could, but I think I'd prefer inheritance in this case — it's easier when all the actual benchmark code is in one folder, and we might want to customize parseTiles in other benchmarks. LayoutDDS also inherits Layout and rewriting it to use composition or util methods for consistency will be very cumbersome.
bench/benchmarks/worker_transfer.js
Outdated
| } | ||
|
|
||
| function barePayload(obj) { | ||
| // strip all transferables from a worker payload |
There was a problem hiding this comment.
Mention the reason why here too.
I wanted to scope it to main thread overhead, because it's a primary cause of stutter. Costly serialization isn't necessarily bad — it doesn't affect the main thread much, and e.g. in #7132, it is used to index a data structure before passing it to the main thread, getting fully transferable payload in return. We might try to include deserialization though, because it happens on the main thread. |
|
We already have a convention for shared benchmark code though -- |
|
@jfirebaugh true, although I still don't see how I could cut out |
Is it possibly to make multiple copies of the instead of removing them? There might be some overhead to transferring arrays and it could be good to capture that. But maybe that isn't necessary right now |
|
@ansis I assumed it's not possible because we don't know beforehand how many times the bench will run. Maybe @jfirebaugh has ideas about that? |
|
Yeah, the number of runs is not deterministic (depends on the measured runtime). I think this solution is fine. |
A new benchmark to measure JSON worker transfer costs for PRs like #7124, #7132 and #7127.
I'm gathering parsed tile/glyph/icon data, serializing it, removing all array buffers (because we can't transfer them repeatedly), and then sending this payload over and over to an empty worker and back to measure the structured cloning impact.
It may be a little contrived, but I don't see any other good way to benchmark this.
We also may need to pick a more representative set of tiles (e.g. a set of dense z11 ones).