Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimization: Shorter option binary representation via invalid value (e.g. -1 == None of option<resource>) #437

Open
cpetig opened this issue Jan 11, 2025 · 3 comments

Comments

@cpetig
Copy link

cpetig commented Jan 11, 2025

Today I realized that option<my-resource> or option<borrow<my-resource>> could have the same size and representation as the resource itself, because (at least in the current bindings) -1 is used as an invalid value for the resource index.

As I didn't find the invalid value nor the optimization documented in the canonical ABI, I wonder whether this would be a reasonable addition to the spec. Similarly string and vector could have defined invalid representations which could optimize the representation of an option.

See https://doc.rust-lang.org/std/option/index.html#representation for the documentation of the Null Pointer Optimization on Rust.

@primoly
Copy link

primoly commented Jan 11, 2025

As I didn't find the invalid value nor the optimization documented in the canonical ABI

You’re probably looking for #284.

@cpetig
Copy link
Author

cpetig commented Jan 11, 2025

Right, so 0 would be the externally agreed invalid id (instead of the -1 I see in wit-bindgen code)

It makes perfect sense but I wonder whether this is already implemented in wasmtime and jco this way (I recall seeing zero handles for the first object of each type many times in the past using these runtimes).

And then this issue proposes to use that as a sentinel value to optimize the canonical representation of option<my-resource> as a mere s32.

@lukewagner
Copy link
Member

Abstractly this makes sense. Mostly, I didn't dig into this sort of optimization initially because I was worried it was a rabbit hole that one could go quite far down in a way that gets baked into a spec that forces N produces+consumers to have to care about, so I wanted to get some implementation feedback and motivation. But if we think this could be a meaningful win in practice, I think it could work.

Because we're currently in the "island of stability" that is wasip2 which we want to maintain in wasip3, I don't think we can make this change without some opt-in canonopt (and then over time we could deprecate the unset option, and then flip the default in 1.0). Doing a whole canonopt for a small optimization seems to require a bit of effort, but perhaps we could fold it in with another batch of ABI changes; say lazy lowering?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants