S benchmark doing 2x work

[adamhaile]

Hi Andrea --
I've seen this benchmark used in a couple other signal implementations but haven't traced down the source. Do you know where it comes from? It has some weird pieces in the S implementation. For instance, this line ...

         S(props.a), S(props.b), S(props.c), S(props.d);

... means that S is actually creating 2 nodes in every place where the other libraries are creating only 1. So S is doing twice the work of the others.

It also disables batching for S but no other library, which seems weird. S should have:

     const run = BATCHED ? S.freeze : (fn) => fn();

Would you mind fixing those in your copy and updating the results?

Other than those issues specific to S, this is almost the worst possible benchmark if you're trying to improve actual application performance. All it tests is update speed of deep intermediate nodes, which happens rarely to never. It doesn't test creation time or memory usage at all, even though those are the biggest factors in app performance.

Overall, though, it's cool to see other fast signals implementations come out. I'm reading through usignal, neat stuff!
-- Adam

[WebReflection]

https://github.com/WebReflection/usignal/blob/main/test/benchmark.js#L1-L4

[adamhaile]

Thanks @WebReflection, I missed that note! I already notified maverick-js a few months ago, and he corrected his version of the benchmark: maverick-js/signals#11 .

[WebReflection]

That leads to a PR to update the test 😜

[adamhaile]

Happy to :)