Not compatible with S.subclock

[irisjae]

Hi Adam! It seems like S.subclock isn't compatible with surplus... which is a shame!

When I substituted s-js in my project for s-js/dist/withsubclocks, the signals from Surplus and the signals from S no longer belong to the same S, and so the dependency detection breaks. So, I tried several things to try fix it. First I tried Surplus.S = S, but then I found out the architecture for subclocks S is quite different from the regular S; surplus promptly complains because S doesn't have S.effect defined. Checking the source code, I assumed S.effect performs a similar function as a regular computation, so I tried adding Surplus.S.effect = S, but then performance basically dies, alas.

Hope you could help clear things up! Cheers

[adamhaile]

Shoot, yeah, I've sort of got two experiments going right now, subclocks and another effort around exposing a lower-level API to the internal dependency graph. S.effect() grew out of the second of those two (it itself is not part of the lower-level API, but the changes to make the lower-level API happen made S.effect() easy). But I haven't merged that lower-level API work back into the subclocks variant yet, because it's still in development. Hence your issues.

How bad did perf get when you tried using plain S() instead of S.effect()? Some of the delta may have been from subclocks: it's a considerably more complicated, and also less optimized, piece of code than main S. In fact, that's the main reason it's not the only version of S -- I wasn't willing to do that until I'd brought perf to a closer level.

[irisjae]

Ahh I see! Let me revert my project back to the S.subclock commit to take a look at what specifically
caused the performance problems. I do think it was some issue with garbage not being collected. I recall having many computations suddenly show up on the console every second.

Am also interested in how your new experiment changes the dependency graph!