Replace ourboros with self_cell in ftml

[Voultapher]

Before:

$ cargo build --target wasm32-unknown-unknown
... 161 dependencies
Finished dev [unoptimized + debuginfo] target(s) in 1m 53s

After:

$ cargo build --target wasm32-unknown-unknown
... 152 dependencies
Finished dev [unoptimized + debuginfo] target(s) in 1m 33s

That's 22% faster in this very rough test. But the 9 fewer dependencies make this seem plausible.

There are still some proc macro dependencies like syn left, but they have nothing to do with self_cell as it has 0 dependencies and doesn't use proc macros.

Disclaimer I'm the author of self_cell.

I would have like to run the tests before and after, but I don't know how to do that for wasm. Please check this works like before. That said. the heavy lifting is done in the type system here and I expect no runtime problems.

[emmiegit]

Yeah, I created a proc macro for building a logger-free version of the library, since logging is a pretty notable performance hit on wasm. Thank you for bringing up this crate, I will take some time and look into this crate as an alternative.

[emmiegit]

After looking at this for a bit, I think this is fine. I'll merge it.

[emmiegit]

@Voultapher, I'm curious, how did you find this repo?

[Monkatraz]

So, I packed this PR up and ran the client/ tests and the results were interesting: At first, I thought there was a serious performance regression - something like 5x slower. However, goofy V8 compile caches and web browser console shenanigans struck, and led me astray.

It seems that this has a performance benefit in browser - about 25ms quicker for SCP-1730, ~150ms to ~125ms. One interesting "regression" is that the WASM binary size increased quite a bit - from ~1750KB to ~2100KB. Not sure why that is, but this binary was already large so I'm not sure if I mind it that much.

It does pass all WASM tests, so no issue there.

[Voultapher]

@Voultapher, I'm curious, how did you find this repo?

Initially I developed this crate for a private use case, but the more it evolved I realized it could replace many ouroboros use cases, so I took a look at the dependents of ouroboros https://crates.io/crates/ouroboros/reverse_dependencies and started opening PRs.

[Voultapher]

It seems that this has a performance benefit in browser - about 25ms quicker for SCP-1730, ~150ms to ~125ms.

Glad to hear it is also better at runtime performance. This is good data to confirm my expectation, that the two performance critical changes I made with the rework help address Voultapher/self_cell#2.

One interesting "regression" is that the WASM binary size increased quite a bit - from ~1750KB to ~2100KB. Not sure why that is, but this binary was already large so I'm not sure if I mind it that much.

The macro only compiles in things it needs and that are asked for, so the only thing I can think of is the crate being no_std and having to use extern crate alloc, please try out this branch where I made the crate not no_std and report back your findings. Add self_cell = { git = "https://github.com/Voultapher/self_cell", branch = "no-no-std" } to your Cargo.toml.

[Monkatraz]

The macro only compiles in things it needs and that are asked for, so the only thing I can think of is the crate being no_std and having to use extern crate alloc, please try out this branch where I made the crate not no_std and report back your findings. Add self_cell = { git = "https://github.com/Voultapher/self_cell", branch = "no-no-std" } to your Cargo.toml.

Alright, so I figured it out. We have to vendor in binaries for our client-side FTML module for the time being, and I apparently hadn't built them in a while and we haven't had a version bump, so they never got reported as out of date.

Having properly compared the two builds now, the actual size difference is... ~1KB. We do compile the WASM with the maximum number of optimizations possible (although not for code size), so it probably makes sense that the code is barely different.

Sorry for reporting that wrong - although, I'll quickly mention how you can test the client-side WASM if you want to, assuming you have Node and NPM:

$ cd client/
$ npm install && npm run bootstrap
$ cd modules/ftml-wasm
$ npm run pack-ftml # or npm run pack-ftml-debug
$ cd ../../         # back to root
$ npm test          # runs all tests

You'll have to repack if you make changes. The built files will be found in client/modules/ftml-wasm/vendor.

[Monkatraz]

The binary size bump is pretty spooky now that I think about it - the only PR that could've done it is #266. And I have no idea why that would've done it - @ammongit, any ideas what's going on there?

[emmiegit]

thanks @Monkatraz @Voultapher