[FEAT] Adds Effect Queue #1061

pzuraq · 2020-03-22T05:45:12Z

This PR prepares the VM for a refactor toward autotracking by extracting
modifiers and wrapping them in "effects". This is short for the term
side-effect, which describes an action run within a function or computation that
doesn't technically have anything to do with the output of that
computation. Modifiers are a form of side-effect, because they don't
directly affect the output of the VM - they schedule a change that
occurs later.

This also presented a problem for autotracking, which is why I started
with this PR. Autotracking operates on the premise that it is watching
state used within a computation - i.e. synchronously. Async actions,
like modifiers, violate the basic premise of autotracking. We were able
to model it with Tags using UpdatableTag, which does allow this type of
lazy structure, but updatable tags have been a major source of
performance issues and bugs in general.

Rather than having the VM be responsible for updating these async
actions, the way to handle this with autotracking would be to have
something else handle it, specifically the place where the actual
computations occur. This is the Effect Queue.

How it works

The VM handles registration and destruction of effects, but the
environment is now responsible for updating them. Effects are scheduled
to run in the same position modifiers were previously, and all effects
in the queue are revalidated after each render.

Ordering is also still guaranteed, in that child effects will always be
triggered before parents. This is because new nodes are prepended to the
tree, and thus any new children are guaranteed to run before their older
parents. Due to the nature of the queue, it's possible that sibling
update order could change and be unpredictable.

Other options

We could use a tree that mirrors the VM tree instead of a queue, but
traversing that tree could end up being fairly expensive, especially if
there are few modifiers. I opted for the simpler solution for the time
being, and figured we could benchmark to see if there is a performance
impact currently, and if so what solutions are better.

Another option would be to make a n-ary tree that simply divides the
effects up evenly in memoization chunks. This might allow us to get some
wins in the general case, when most modifiers have not changed.

Depends on #1060

This PR prepares the VM for a refactor toward autotracking by extracting modifiers and wrapping them in "effects". This is short for the term [side-effect](https://en.wikipedia.org/wiki/Side_effect_(computer_science)), which describes an action run within a function or computation that doesn't technically have anything to do with the _output_ of that computation. Modifiers are a form of side-effect, because they don't directly affect the output of the VM - they schedule a change that occurs _later_. This also presented a problem for autotracking, which is why I started with this PR. Autotracking operates on the premise that it is watching state used within a computation - i.e. _synchronously_. Async actions, like modifiers, violate the basic premise of autotracking. We were able to model it with Tags using UpdatableTag, which does allow this type of lazy structure, but updatable tags have been a major source of performance issues and bugs in general. Rather than having the VM be responsible for updating these async actions, the way to handle this with autotracking would be to have something _else_ handle it, specifically the place where the actual computations _occur_. This is the Effect Queue. \## How it works The VM handles registration and destruction of effects, but the environment is now responsible for updating them. Effects are scheduled to run in the same position modifiers were previously, and all effects in the queue are revalidated after each render. Ordering is also still guaranteed, in that child effects will always be triggered before parents. This is because new nodes are prepended to the tree, and thus any new children are guaranteed to run before their older parents. Due to the nature of the queue, it's possible that sibling update order could change and be unpredictable. \## Other options We could use a tree that mirrors the VM tree instead of a queue, but traversing that tree could end up being fairly expensive, especially if there are few modifiers. I opted for the simpler solution for the time being, and figured we could benchmark to see if there is a performance impact currently, and if so what solutions are better. Another option would be to make a n-ary tree that simply divides the effects up evenly in memoization chunks. This might allow us to get some wins in the general case, when most modifiers have not changed.

rwjblue · 2020-06-08T18:28:20Z

CI failure is linting related:

$ eslint . --cache --ext .js,.ts

/home/runner/work/glimmer-vm/glimmer-vm/packages/@glimmer/integration-tests/test/modifiers-test.ts
  1:9  error  Replace `·RenderTest,·jitSuite,·test,·Count,·tracked,·EmberishGlimmerComponent,·EmberishGlimmerArgs·` with `⏎··RenderTest,⏎··jitSuite,⏎··test,⏎··Count,⏎··tracked,⏎··EmberishGlimmerComponent,⏎··EmberishGlimmerArgs,⏎`  prettier/prettier

A quick yarn eslint --fix . --ext .js,.ts should resolve

pzuraq · 2020-06-08T18:47:37Z

packages/@glimmer/runtime/lib/effects.ts

+   * _prepended_ to any pre-existing effects. For instance, let's say that the
+   * queue started off in this state after our first render pass:
+   *
+   *   A, B, C


Add an ASCII graph for the tree of nodes

pzuraq · 2020-06-08T19:08:28Z

packages/@glimmer/runtime/lib/environment.ts

-  return true;
-}
-
-export class ScopeImpl<C extends JitOrAotBlock> implements PartialScope<C> {


This was moved to scope.ts since the environment.ts file was getting large and covering too many concerns.

Will break this out into a separate PR

pzuraq · 2020-06-08T19:10:55Z

packages/@glimmer/integration-tests/test/modifiers-test.ts

+    component!.showing = true;
+    this.rerender();
+
+    assert.deepEqual(inserts, ['outer', 'inner'], 'inner modifier insert called');


Should reset inserts between each assertion

pzuraq · 2020-06-08T19:24:32Z

packages/@glimmer/runtime/lib/effects.ts

+  revalidate = () => this.effects.forEachNode(n => n.value.createOrUpdate());
+}
+
+export class EffectManager {


Rename to EffectsManager

pzuraq · 2020-06-08T19:32:36Z

packages/@glimmer/runtime/lib/effects.ts

+    for (let phase of effectPhases) {
+      let queue = queues[phase];
+
+      scheduleEffects(phase, queue.revalidate);


Add a unit test to ensure that scheduleEffects can be called asynchronously and the rest of the EffectManager continues to work properly.

pzuraq · 2020-06-08T19:36:54Z

packages/@glimmer/runtime/lib/effects.ts

+
+  private didSetup = false;
+
+  createOrUpdate = memo(() => {


Update this to run, and update ModifierManager to just include run

pzuraq · 2021-05-20T00:12:39Z

Superceded by #1310

pzuraq mentioned this pull request Mar 22, 2020

[REFACTOR] Refactors the VM to use autotracking #1062

Closed

pzuraq force-pushed the feat/effect-queue branch from 8399d79 to 87f1fea Compare March 22, 2020 14:56

pzuraq mentioned this pull request Mar 22, 2020

[FEAT] Adds memoizeTracked #1060

Merged

pzuraq force-pushed the feat/effect-queue branch 2 times, most recently from a111332 to b217e8d Compare March 22, 2020 15:54

lifeart mentioned this pull request Mar 23, 2020

[breaking] Stop running in the next loop lifeart/ember-ref-modifier#232

Closed

pzuraq force-pushed the feat/effect-queue branch from b217e8d to 071d1e3 Compare March 26, 2020 17:38

pzuraq force-pushed the feat/effect-queue branch from 071d1e3 to f10611c Compare June 5, 2020 00:47

pzuraq force-pushed the feat/effect-queue branch from f10611c to 8c61278 Compare June 5, 2020 22:07

rwjblue added breaking enhancement labels Jun 8, 2020

pzuraq commented Jun 8, 2020

View reviewed changes

pzuraq mentioned this pull request May 19, 2021

Adds EffectsManager #1310

Open

pzuraq closed this May 20, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[FEAT] Adds Effect Queue #1061

[FEAT] Adds Effect Queue #1061

pzuraq commented Mar 22, 2020 •

edited

Loading

rwjblue commented Jun 8, 2020 •

edited

Loading

pzuraq Jun 8, 2020

pzuraq Jun 8, 2020

pzuraq Jun 8, 2020

pzuraq Jun 8, 2020

pzuraq Jun 8, 2020

pzuraq Jun 8, 2020

pzuraq Jun 8, 2020

pzuraq commented May 20, 2021

[FEAT] Adds Effect Queue #1061

[FEAT] Adds Effect Queue #1061

Conversation

pzuraq commented Mar 22, 2020 • edited Loading

How it works

Other options

rwjblue commented Jun 8, 2020 • edited Loading

pzuraq Jun 8, 2020

Choose a reason for hiding this comment

pzuraq Jun 8, 2020

Choose a reason for hiding this comment

pzuraq Jun 8, 2020

Choose a reason for hiding this comment

pzuraq Jun 8, 2020

Choose a reason for hiding this comment

pzuraq Jun 8, 2020

Choose a reason for hiding this comment

pzuraq Jun 8, 2020

Choose a reason for hiding this comment

pzuraq Jun 8, 2020

Choose a reason for hiding this comment

pzuraq commented May 20, 2021

pzuraq commented Mar 22, 2020 •

edited

Loading

rwjblue commented Jun 8, 2020 •

edited

Loading