Complete example using Transferable objects with the return value being Transferred?

[Swizzy]

Hi,

Is there any chance you could create a complete example showing how to send a request to a WebWorker and have the result be returned as a Transferable object? i've been trying to do that with a background task i've been trying to optimize - it's currently taking ~9s with JSON and ~6s with a memory packed byte array - those 6s appear to be the time it takes from the serialization completing and getting the data from the WebWorker to the Window task and adding [return: WorkerTransfer] to my method doesn't appear to change anything when the return type is a ArrayBuffer which should be transferable from what i understand?

[Swizzy]

Basically, i would like to see a example showing a method that accepts a ArrayBuffer and pretty much just returns it right back - preferably with a roundtrip Stopwatch to see how long it takes to send a ~250kb blob of data.

[LostBeard]

Hope this helps. I changed the amount of data to 50MB. When I used 250KB there wasn't a noticeable difference.

WorkerTransferExample

Live Demo

• The demo generates 50MB of random data and sends it to a web worker for processing.
• The demo first sends the data without using WorkerTransfer, which results in the data being copied to the worker.
• Then the demo sends the data using WorkerTransfer, which results in the data being transferred to the worker (the original data becomes detached and cannot be used anymore).
• The demo measures and displays the time taken for each operation and verifies data integrity.

Example output from the demo:

Processed without WorkerTransfer 52428800 bytes in 27 ms
ArrayBuffer is detached: False
Data integrity verified: True
Processed with WorkerTransfer 52428800 bytes in 10 ms
ArrayBuffer is detached: True
Data integrity verified: True
Done

[Swizzy]

Thank you - that's perfect - and i realized late last night that i had messed up my measurements - i was naively thinking that i could get a timestamp using Stopwatch.GetTimestamp() from within the WebWorker to then compare that against an equivalent Timestamp from the outside and get the difference between them as the time it takes to transfer the data - that doesn't work since Stopwatch doesn't give you an exact timestamp from a given point in time - it's instead (from my understanding now) based on how long the process has been running essentially which is obviously going to be different between the WebWorker and the main UI thread.

[LostBeard]

I modified that example some. There are now 3 tests. Test 3 takes and returns a byte[] instead of an ArrayBuffer. The ServiceCallDispatcher (class that handles the worker calls) internally converts the byte[] to an ArrayBuffer and transfers it to the worker making it work in a similar way as Test 2, that uses an ArrayBuffer and the WorkerTransfer attribute, with similar performance.

[Swizzy]

I think the byte[] should work the same way as using a ArrayBuffer directly - i.e. require you to explicitly specify the WorkerTransfer attribute - otherwise it's unexpected behavior in a way that i lose the reference when passing it to the worker, i do appreciate that byte[] can effectively be treated as a ArrayBuffer under the hood - but - i think it should be controllable whether or not a transfer should happen as it may have unexpected consequences otherwise.

[LostBeard]

I think you are misunderstanding. What unexpected behavior are you referring to? The byte[] is not lost in either side when it is sent to the worker. Transferable is used automatically for byte[] because a copy of byte[] is made when you pass it to Javascript to call postMessage. That copy is transferred to the worker via postMessage, not the actual byte[]. Using transferable automatically there prevents an additional copy. That is all.

[Swizzy]

Thanks for clarifying that - i misunderstood how it actually works :)

[LostBeard]

Not a problem. It took a lot of work to get it to work as is, and some things are not as straight forward as it seems. Always glad to help.

[LostBeard]

I see why you would have thought that. My description of what was happening with byte[] wasn't very clear in the demo project so I changed it to better describe what is happening.