Optimising RemGlk-rs

[Dannii]

@Hanna

It was definitely the right choice during initial development. But given that the JSON protocol is now fully implemented and only evolves at a glacial pace, I think that it’s possible to write the JSON wrangling in a way that’s not much harder to maintain but has significant size benefits.

I wrote RemGlk-rs in Rust in large part to avoid having to do any manual JSON parsing. I’m also intending to use Serde for autosaves with a binary format rather than JSON. So removing Serde is not something I anticipate considering, it’s really an integral part of the library. But maybe there are ways to optimise how I’m using Serde.

@Hanna

Per cargo tree, it’s used via chrono. There’s probably decent savings to be had by (partially or entirely) pushing the date/time functions into JS just to have control of how much machinery is needed on the wasm side to talk to JS (necessary at least for the current system time and local UTC offset).

wasm-bindgen isn’t compiled by Emglken, and indeed the Chrono dependencies don’t include it for the emscripten target. That said, I’m not super happy with Chrono and would consider swapping it for something else.

@Hanna

When they are used, is there any problem with leaving those functions to JS (which already has the necessary tables), as done in previous versions of emglken?

Other than the performance hit from switching between WASM and JS (which would be identical to old versions of Emglken), not really. It will be the first thing I try to reduce file size.

@Hanna

A decently large chunk of Rust std::fmt code consists of Debug impls that are probably only needed for panic messages and could probably be reduced or avoided entirely.

I’m not doing any significant string formatting in RemGlk-rs and have just used format! as a convenience. It might be possible to cut this out.

I think exchanging some generics for dynamic dispatch would likely reduce the file size a lot, though I haven’t investigate the details yet.