Optimise comparison with singleton custom types on JavaScript

[GearsDatapacks]

Currently, if you have some code like this:

pub type Wibble {
  Wibble
  Wobble
}

pub fn is_wibble(w: Wibble) -> Bool {
  w == Wibble
}

On the JavaScript target, this code is generated for the is_wibble function:

export function is_wibble(w) {
  return isEqual(w, new Wibble());
}

This works, but it's very slow. It needs to construct a new Wibble, and then call the isEqual function, which supports any shape of data, and so does a lot of extra logic which isn't necessary.

For the case when we're comparing to a "singleton" custom type, i.e. one with no fields, we could instead generate this:

export function is_wibble(w) {
  return w instanceof Wibble;
}

This is what we generate for pattern matching. With some basic benchmarks, it seems this is over 10x faster:

Input               Function                       IPS           Min           P99
100k elements       equality                   40.0693       23.9345       27.1689
100k elements       instanceof                523.1122        1.5164        4.1579

[giacomocavalieri]

Sounds like a good first issue!

[lpil]

Great idea!

We've been talking about introducing singleton values for variants without any fields, so we don't have to construct a new instance for each usage. I wonder if doing w === the_wibble_singleton || w instanceof Wibble would improve performance for the singleton, and to what extent it would hurt performance for non-singleton code + how much it would increase compressed code size.

[GearsDatapacks]

Here's a benchmark I put together for that, comparing current equality, just an instanceof check, just an equality check with a singleton, and the combined approach mentioned above. I've done 3 inputs: One is a list containing 50% Wibbles and 50% Wobbles. One is a list containing only Wibble, the last contains only Wobble.

Input               Function                       IPS           Min           P99
50/50               equality                   49.0317       18.7387       39.0100
50/50               instanceof                658.4750        1.4840        1.7985
50/50               singleton                 799.4373        1.2025        1.6991
50/50               both                      658.7560        1.4713        2.2350
all Wibble          equality                   41.3033       23.8008       26.1263
all Wibble          instanceof                712.1356        1.3708        1.5471
all Wibble          singleton                 835.5677        1.1676        1.3381
all Wibble          both                      783.8846        1.2418        1.5262
all Wobble          equality                   76.7850       12.7801       13.3744
all Wobble          instanceof                611.5547        1.5968        1.9671
all Wobble          singleton                 796.6315        1.2371        1.4331
all Wobble          both                      576.6833        1.6851        1.9218

The singleton comparison is always fasted, the combined approach is fast when the comparison is succeeding, but slower than plain instanceof when it fails.

All of them are more than 10x the speed of the current implementation though, so any of these would be a huge improvement.

[lpil]

Let's do the instanceof version and we can switch to === once we have the nice new API for FFI to use.

[re-masashi]

can i work on this?

[GearsDatapacks]

Go for it!

[re-masashi]

thanks a ton!

[re-masashi]

do i need to add any new tests or anything like that?
i added some comments along with the code.

[giacomocavalieri]

Usually it's best to add tests for the specific change, so here you'd want to have a test that makes sure that the optimisation is applied :)

[re-masashi]

okay!

[re-masashi]

this might be a stupid question but how do i compare against the expected output?

#[test]
fn singleton_record_inequality() {
    assert_js!(
        r#"
pub type Wibble {
  Wibble
  Wobble
}

pub fn is_not_wibble(w: Wibble) -> Bool {
  w != Wibble
}
"#,
    );
}

doing this kind of a thing rn, but this doesnt really check against an expected output or something.

also, do i need to add the snapshots or something like that?
is there some sort of contribution guideline explaining this?

sorry if i missed something