quixe
quixe copied to clipboard
erkyrath
Switch over to JS typed arrays (Uint8Array, Uint32Array)
The last time I tested this, it wasn't any faster than regular JS arrays. However, that was many browser optimizations ago; it might be a good idea now.
We have seen problems with very large Blorb files (hundreds of megabytes), which can be represented in-memory as Node Buffers or Uint8Arrays, but not naive Number arrays.
Probably easiest to use DataViews. I made an extension to DataView which also has support for getting and setting a block of data too.
Well, that was only hanging around for eight years, right?
Done now.
The speedup remains tiny (maybe 3%). I suspect JS engine optimizations have long since gotten to the point where they do this automatically. However, it's tidier to do it explicitly.
Does it support a Uint8Array being provided directly?
GlkApi would also need to support typed arrays for the full benefits to be apparent.
I couldn't see you make any changes for the GlkApi dispatch, so the unicode functions might be broken right now (unless it's still passing Arrays to them?): https://github.com/erkyrath/glkote/issues/27
You can pass in a Uint8Array or an Array by writing
GiLoad.load_run(OPTIONS, array, { format:'array' })
This covers Quixe changes. I ran most of the usual unit tests. (Well, not all of them, but the ones dealing with Unicode and Blorb image loading.) I'll check the unicasetest tests you mentioned.
Nope, nothing broken in the unit tests. I'm not using Uint32Array anywhere, so there's no reason to have triggered the error you discovered there.
I still want to try using Uint32Array for the stack, or (more importantly) frame.valstack.
I found for Z-Machine that it was really nice to store the stack in the Quetzal format, except for needing to swap the bytes before saving. The locals could then just be a slice on the typed array, writing it directly.
It might be similar for Glulx. There are JS libraries for swapping bytes, but I haven't looked into them specifically yet.