Belt vs Js performance

Hi there ! :slight_smile:

Just posting here to clarify my confusion. I thought the Js modules (because they’re 0 cost) were always more performant than the helpers coming from the Belt library? I’m reading the docs and I see it’s written that Belt provides “Better performance and smaller code size running on the JS platform”.

Is this phrase maybe not comparing Belt to Js ? Are there some examples where Belt is more performant than Js?

I believe that statement is meant in comparison to the OCaml stdlib, which also ships with ReScript. For example, using the Belt.Map module will be much more performant than using the OCaml Map module.

The Js modules will always produce a smaller code size because they’re all (almost) zero-cost bindings. As for performance between Belt and Js, my experience has found that they’re basically the same.

There are a few cases where Belt’s functions actually can be faster, since they’re implemented differently than in JS. For example, Belt.Array.map is simply a loop. The built-in JS map is slower because it does things like check for sparse arrays. (Sparse arrays aren’t allowed by the ReScript type-checker, so Belt doesn’t account for them.) Overall, these cases aren’t important to know unless you’re really trying to optimize a benchmark, in which case you’re better off just using a loop directly.

5 Likes

It would be really cool if while resolving the duplication of Js.x2 and Belt and “a standard lib” (I know there’s some ongoing other discussions around this) we could also make these faster versions more easily discoverable and usable (e.g. without having to know the implementations of Belt and Js to know which one to use).

3 Likes