preview2 shim browser filesystem writeViaStream has O(n^2) overhead due to repeatedly concatenating buffers

[TerrorJack]

See

jco/packages/preview2-shim/lib/browser/filesystem.js

Line 123 in f92eaa5

writeViaStream(_offset) {

, when this is invoked repeatedly to do a lot of small appends, there is O(n^2) slowdown due to repeatedly concatenating buffers. I noticed this when working on bjorn3/browser_wasi_shim#95; almost all wasi in-memory vfs implementation written in js/ts I can find has the same issue, including this one.

[guest271314]

Why keep creating a new Uint8Array? We have resizable ArrayBuffers now. We can resize() and write to the same original ArrayBuffer.

[vados-cosmonic]

Hey @TerrorJack & @guest271314 these are good points.

I don't think there's a good reason that we're not reusing buffers there -- I'd be happy to review any contributions to fix the inefficiency here. At the very least reusing a large Uint8Array and optimistically using a resizable ArrayBuffer if the browser supports it. Maybe it's been long enough now that we can go straight to using ArrayBuffer -- the caniuse data is encouraging.

[guest271314]

Resizable ArrayBuffer is shipped, out and about. I mentioned that option before looking at the browser_wasi_shim issue, which looks like it uses what I was thinking about.

[guest271314]

Where does buf come from here?

write(buf) {

[vados-cosmonic]

That buf you're looking at (this one, right?) comes from the actual component -- when the component calls write on the resource which triggers the OutputStream#write in the host (WIT output-stream in the WASI interfaces)

[guest271314]

I'm wondering if that buf is user-defined or defined in filesystem.js somewhere and the user just deals with the pre-supplied object?

If defined in the filesystem.js file, where? So I can change it to a resizable ArraBuffer, write a test, see the difference, if any.

[vados-cosmonic]

Ah so that's a special case of "lifting" (in the Component Model sense) a WIT value (list<u8>) out of a component during a call to the host (into some T the host knows how to deal with/represents the type).

You can find the special case for that here.

On either side of the bounary, the list<u8> takes different forms (in jco as a host, a Uint8Array), in a Rust component a Vec<u8> (or more efficiently bytes::Bytes, etc).

[guest271314]

I'll have to do more reading about and testing the component model. Right now I just see a JavaScript ArrayBuffer that I was going to change to a resizable ArrayBuffer in the code where referred to, and as I do generally, when done with the procedure, resize(0).

[guest271314]

More specifically, change entry.source to a resizable ArrayBuffer to begin with and stop re-constructing a new Uint8Array in JavaScript.

[guest271314]

This is probably more expensive than it has to be

entry.source = newSource;

Tests will determine id something changes re performance.

[guest271314]

E.g., https://github.com/guest271314/NativeMessagingHosts/blob/48c497ad61f4545bac05f7c812d5bf1d6169dd1c/nm_host.js#L55-L79, https://github.com/guest271314/NativeMessagingHosts/blob/main/nm_typescript.ts#L35-L76.