proposal-signals

proposal-signals copied to clipboard

in options for both Signal.State and Signal.Computed, an equals function is allowed to be passed to change how "dirtiness" is calculated -- it could be an optimization to allow false instead of requiring a function to then call every time -- we could skip part of the dirtying algo.

thoughts?

might be premature optimization - i'd guess a modern JIT would inline a constant function returning false and eliminate what's left of it.

that is an interesting point about JIT -- I made a little test to see what happens (perf.link)

I only have these two browsers atm:

• FireFox (Dev, 127.0a1)
  • just false is faster (which is what I would expect)
• Chrome: (124.0.6367.118)
  • calling a function is faster than just having false, which is very surprising

Node and Bun are basically the same:

Modifying @NullVoxPopuli's test (perf.link) to include a loop results in the false version being faster in FireFox (Dev, 126.0b1), Google Chrome (124.0.6367.202), and Safari (17.4.1) on an M1 MacBook Air running macOS 14.4.1

PS: Not sure if my version is benchmarking the right thing though, benchmarking is hard 😣

This is about more than the speed of calling the function: the signals system can have a more clear understanding of what's going on if it knows that it will always be false.

And to add on to that, if it's faster to always call, an engine will set its internal equals field to a private pre-optimized global function that always returns false.

Not that I even slightly find this likely, though. Not when it's only 3-4 instructions and 1 load total compared to well over a dozen plus a multiply indirect call.