Transfer buffers to/from worker to avoid cloning #113
Conversation
|
From a completely unscientific comparison of the loading animations in prod and in the deploy preview, it looks like it takes about a third of the time to compute the texture with the optimisation than it does without! |
|
Something strange, though, which also occured without the optimisation:
|
|
Never mind, some color scales just take a lot more computation time than others. 😅 |
| mergeState({ loading: true }); | ||
|
|
||
| // Prepare transferable buffer to avoid cloning values array | ||
| const typedValues = Float64Array.from(values); |
There was a problem hiding this comment.
Float 64 is the type for numbers in JS. Eventually, we may have to parse the JSON (or whatever format) returned by the server and create the appropriate typed array right away to optimise things further.
| mergeState({ | ||
| loading: false, | ||
| textureData: await proxy.computeTextureData( | ||
| values, | ||
| transfer(typedValues, [typedValues.buffer]), |
There was a problem hiding this comment.
Comlink's transfer method uses the same syntax as postMessage to transfer a buffer https://devdocs.io/dom/worker/postmessage - https://github.com/GoogleChromeLabs/comlink#comlinktransfervalue-transferables-and-comlinkproxyvalue
| @@ -16,12 +16,15 @@ function computeTextureData( | |||
| const colorScale = scaleSequential(INTERPOLATORS[colorMap]); | |||
|
|
|||
| // Compute RGB color array for each datapoint `[[<r>, <g>, <b>], [<r>, <g>, <b>], ...]` | |||
| const colors = values.map(val => { | |||
| const colors = values.reduce<number[]>((acc, val) => { | |||
There was a problem hiding this comment.
I replace map with reduce to avoid having to flatten the array afterwards.
This should improve the performance of texture computations.