chore: only call mark_reactions
when updating a source
#12272
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This implements something I've been wanting to get at for a while. Currently, we call
mark_reactions
in two places — when updating a source, and when updating a derived. The latter doesn't really make sense — we should only mark reactions when sources update.This fixes that, and allows us to simplify things a bit — there's no more
force_schedule
. It also allows us to movemark_reactions
(andinspect_effects
) out of the neverending module that isruntime.js
and intosources.js
.It works by using version tracking as the universal mechanism for knowing if a reaction is dirty. We can use
current_version
for effects, rather thanincrement_version()
, so this doesn't increase the (infinitesimal) danger of an overflow. (I thought I'd be able to use the same trick for deriveds, but it doesn't work for some reason — will continue investigating.)Performance-wise it's basically neutral, except forWith the most recent commits, this is significantly faster thankairo_mux_unowned
which is slower. I'm not exactly sure why but my hunch is that it's somehow related to the fact that we're pushing reactions further down — it feels weird that we do that there in addition to doing it insideupdate_reaction
. Feels off, will look into it.main
. I'm still a bit confused by theis_unowned
stuff insidecheck_dirtiness
, but we can worry about that another time.Before submitting the PR, please make sure you do the following
feat:
,fix:
,chore:
, ordocs:
.Tests and linting
pnpm test
and lint the project withpnpm lint