Callback chain refactoring and performance improvements

[Marc-Andre-Rivet]

Part of a larger performance rework. This PR proposes to break up the callback chain into smaller constituents by rewriting it using (1) a state-machine model where callbacks transition through various states (eg. requested, prioritized, executing, watched, executed, stored) that offer more limited logic each step of the way and hopefully easier optimization paths. (2) by handling derived store props and state transitions in (1) through the use of store observers.

• remove pendingCallbacks from the store and replace it with more easily used data structures for evaluating if:
  a. the app is ready (no callbacks to process)
  b. the component (or one if its children, for loading components) is awaiting the result of a callback
• remove connect from TreeContainer component
  a. Resolve loading_state in parent
  b. Resolve a loading state hash that can be used to decide if the parent needs to be re-rendered for its children
  c. Use context to provide shared data that do not affect re-renders (eg. graphs, etc.) - this replaces the connect usage

Companions
DCC: plotly/dash-core-components#810 (testing only)
Table: plotly/dash-table#785 (contains a tabe fix)
Docs: https://github.com/plotly/dash-docs/pull/888 (testing only)

There are some issues in the companion PRs but they seem related to CI only / the tests themselves are passing.

• Percy diff for table in dash-docs
  https://percy.io/plotly/dash-docs/builds/5455921/view/319601375/1280?mode=diff&browser=firefox&snapshot=319601375 (missing number of pages)

---

Performance

Gains increase as the number of displayed elements increases and can be explained by (1) less renders, (2) less expensive checks for states (eg. is_loading, shouldComponentUpdate).

1. dash.plotly.com/ vs branch (few components, none heavy, no callbacks)
   JS time: 625ms vs 592ms (20 runs, p=0.08)
   Total time: 1198ms vs 888ms (20 runs, p<=0.001)

2. dash.plotly.com/datatable/interactivity (few components, heavy: table/graph, w/ callbacks)
   No significant difference after 10 runs.
   JS time: 2488ms vs 2435ms (10 runs, p ~ 0.70)
   Total time: 3430ms vs 3369ms (10 runs, p ~ 0.70)

3. HTML Table with 1000 rows (dev vs. branch) (lots of lightweight components, no callbacks)
   JS time: 2706ms vs 1072ms (5 runs, p<=0.001)
   Total time: 3460ms vs 1817ms (5 runs, p<=0.001)

4. HTML Table with 5000 rows (dev vs. branch) (lots of lightweight components, no callbacks)
   JS time: 8412ms vs 3835ms (5 runs, p<=0.001)
   Total time: N/A, devtools terminated test too early for dev and numbers were no significant - JS times were obtained by starting/ending the tests manually

[Marc-Andre-Rivet]

@alexcjohnson

Would it be worth 🔒 that a little tighter by asserting the correct number of callback invocations in one or two of the existing wildcard tests?

be36ab4

Also, redux_state_rqs now supports both legacy and current implementation for Dash matrix testing with afcdba9 and 63f14af

[alexcjohnson]

Fantastic, I think you've got it! 💃

[Marc-Andre-Rivet]

Part of a larger performance rework. This PR proposes to break up the callback chain into smaller constituents by rewriting it using (1) a state-machine model where callbacks transition through various states (eg. requested, prioritized, executing, watched, executed, stored) that offer more limited logic each step of the way and hopefully easier optimization paths. (2) by handling derived store props and state transitions in (1) through the use of store observers.

• remove pendingCallbacks from the store and replace it with more easily used data structures for evaluating if:
  a. the app is ready (no callbacks to process)
  b. the component (or one if its children, for loading components) is awaiting the result of a callback
• remove connect from TreeContainer component
  a. Resolve loading_state in parent
  b. Resolve a loading state hash that can be used to decide if the parent needs to be re-rendered for its children
  c. Use context to provide shared data that do not affect re-renders (eg. graphs, etc.) - this replaces the connect usage

Companions
DCC: plotly/dash-core-components#810 (testing only)
Table: plotly/dash-table#785 (contains a tabe fix)
Docs: https://github.com/plotly/dash-docs/pull/888 (testing only)

There are some issues in the companion PRs but they seem related to CI only / the tests themselves are passing.

• Percy diff for table in dash-docs
  https://percy.io/plotly/dash-docs/builds/5455921/view/319601375/1280?mode=diff&browser=firefox&snapshot=319601375 (missing number of pages)

---

Performance

Gains increase as the number of displayed elements increases and can be explained by (1) less renders, (2) less expensive checks for states (eg. is_loading, shouldComponentUpdate).

1. dash.plotly.com/ vs branch (few components, none heavy, no callbacks)
   JS time: 625ms vs 592ms (20 runs, p=0.08)
   Total time: 1198ms vs 888ms (20 runs, p<=0.001)

2. dash.plotly.com/datatable/interactivity (few components, heavy: table/graph, w/ callbacks)
   No significant difference after 10 runs.
   JS time: 2488ms vs 2435ms (10 runs, p ~ 0.70)
   Total time: 3430ms vs 3369ms (10 runs, p ~ 0.70)

3. HTML Table with 1000 rows (dev vs. branch) (lots of lightweight components, no callbacks)
   JS time: 2706ms vs 1072ms (5 runs, p<=0.001)
   Total time: 3460ms vs 1817ms (5 runs, p<=0.001)

4. HTML Table with 5000 rows (dev vs. branch) (lots of lightweight components, no callbacks)
   JS time: 8412ms vs 3835ms (5 runs, p<=0.001)
   Total time: N/A, devtools terminated test too early for dev and numbers were no significant - JS times were obtained by starting/ending the tests manually

[Marc-Andre-Rivet]

@alexcjohnson

Would it be worth 🔒 that a little tighter by asserting the correct number of callback invocations in one or two of the existing wildcard tests?

be36ab4

Also, redux_state_rqs now supports both legacy and current implementation for Dash matrix testing with afcdba9 and 63f14af

[alexcjohnson]

Fantastic, I think you've got it! 💃

[Marc-Andre-Rivet]

Part of a larger performance rework. This PR proposes to break up the callback chain into smaller constituents by rewriting it using (1) a state-machine model where callbacks transition through various states (eg. requested, prioritized, executing, watched, executed, stored) that offer more limited logic each step of the way and hopefully easier optimization paths. (2) by handling derived store props and state transitions in (1) through the use of store observers.

• remove pendingCallbacks from the store and replace it with more easily used data structures for evaluating if:
  a. the app is ready (no callbacks to process)
  b. the component (or one if its children, for loading components) is awaiting the result of a callback
• remove connect from TreeContainer component
  a. Resolve loading_state in parent
  b. Resolve a loading state hash that can be used to decide if the parent needs to be re-rendered for its children
  c. Use context to provide shared data that do not affect re-renders (eg. graphs, etc.) - this replaces the connect usage

Companions
DCC: plotly/dash-core-components#810 (testing only)
Table: plotly/dash-table#785 (contains a tabe fix)
Docs: https://github.com/plotly/dash-docs/pull/888 (testing only)

There are some issues in the companion PRs but they seem related to CI only / the tests themselves are passing.

• Percy diff for table in dash-docs
  https://percy.io/plotly/dash-docs/builds/5455921/view/319601375/1280?mode=diff&browser=firefox&snapshot=319601375 (missing number of pages)

---

Performance

Gains increase as the number of displayed elements increases and can be explained by (1) less renders, (2) less expensive checks for states (eg. is_loading, shouldComponentUpdate).

1. dash.plotly.com/ vs branch (few components, none heavy, no callbacks)
   JS time: 625ms vs 592ms (20 runs, p=0.08)
   Total time: 1198ms vs 888ms (20 runs, p<=0.001)

2. dash.plotly.com/datatable/interactivity (few components, heavy: table/graph, w/ callbacks)
   No significant difference after 10 runs.
   JS time: 2488ms vs 2435ms (10 runs, p ~ 0.70)
   Total time: 3430ms vs 3369ms (10 runs, p ~ 0.70)

3. HTML Table with 1000 rows (dev vs. branch) (lots of lightweight components, no callbacks)
   JS time: 2706ms vs 1072ms (5 runs, p<=0.001)
   Total time: 3460ms vs 1817ms (5 runs, p<=0.001)

4. HTML Table with 5000 rows (dev vs. branch) (lots of lightweight components, no callbacks)
   JS time: 8412ms vs 3835ms (5 runs, p<=0.001)
   Total time: N/A, devtools terminated test too early for dev and numbers were no significant - JS times were obtained by starting/ending the tests manually

[Marc-Andre-Rivet]

@alexcjohnson

Would it be worth 🔒 that a little tighter by asserting the correct number of callback invocations in one or two of the existing wildcard tests?

be36ab4

Also, redux_state_rqs now supports both legacy and current implementation for Dash matrix testing with afcdba9 and 63f14af

[alexcjohnson]

Fantastic, I think you've got it! 💃

[Marc-Andre-Rivet]

Part of a larger performance rework. This PR proposes to break up the callback chain into smaller constituents by rewriting it using (1) a state-machine model where callbacks transition through various states (eg. requested, prioritized, executing, watched, executed, stored) that offer more limited logic each step of the way and hopefully easier optimization paths. (2) by handling derived store props and state transitions in (1) through the use of store observers.

• remove pendingCallbacks from the store and replace it with more easily used data structures for evaluating if:
  a. the app is ready (no callbacks to process)
  b. the component (or one if its children, for loading components) is awaiting the result of a callback
• remove connect from TreeContainer component
  a. Resolve loading_state in parent
  b. Resolve a loading state hash that can be used to decide if the parent needs to be re-rendered for its children
  c. Use context to provide shared data that do not affect re-renders (eg. graphs, etc.) - this replaces the connect usage

Companions
DCC: plotly/dash-core-components#810 (testing only)
Table: plotly/dash-table#785 (contains a tabe fix)
Docs: https://github.com/plotly/dash-docs/pull/888 (testing only)

There are some issues in the companion PRs but they seem related to CI only / the tests themselves are passing.

• Percy diff for table in dash-docs
  https://percy.io/plotly/dash-docs/builds/5455921/view/319601375/1280?mode=diff&browser=firefox&snapshot=319601375 (missing number of pages)

---

Performance

Gains increase as the number of displayed elements increases and can be explained by (1) less renders, (2) less expensive checks for states (eg. is_loading, shouldComponentUpdate).

1. dash.plotly.com/ vs branch (few components, none heavy, no callbacks)
   JS time: 625ms vs 592ms (20 runs, p=0.08)
   Total time: 1198ms vs 888ms (20 runs, p<=0.001)

2. dash.plotly.com/datatable/interactivity (few components, heavy: table/graph, w/ callbacks)
   No significant difference after 10 runs.
   JS time: 2488ms vs 2435ms (10 runs, p ~ 0.70)
   Total time: 3430ms vs 3369ms (10 runs, p ~ 0.70)

3. HTML Table with 1000 rows (dev vs. branch) (lots of lightweight components, no callbacks)
   JS time: 2706ms vs 1072ms (5 runs, p<=0.001)
   Total time: 3460ms vs 1817ms (5 runs, p<=0.001)

4. HTML Table with 5000 rows (dev vs. branch) (lots of lightweight components, no callbacks)
   JS time: 8412ms vs 3835ms (5 runs, p<=0.001)
   Total time: N/A, devtools terminated test too early for dev and numbers were no significant - JS times were obtained by starting/ending the tests manually

[Marc-Andre-Rivet]

@alexcjohnson

Would it be worth 🔒 that a little tighter by asserting the correct number of callback invocations in one or two of the existing wildcard tests?

be36ab4

Also, redux_state_rqs now supports both legacy and current implementation for Dash matrix testing with afcdba9 and 63f14af

[alexcjohnson]

Fantastic, I think you've got it! 💃

[Marc-Andre-Rivet]

Part of a larger performance rework. This PR proposes to break up the callback chain into smaller constituents by rewriting it using (1) a state-machine model where callbacks transition through various states (eg. requested, prioritized, executing, watched, executed, stored) that offer more limited logic each step of the way and hopefully easier optimization paths. (2) by handling derived store props and state transitions in (1) through the use of store observers.

• remove pendingCallbacks from the store and replace it with more easily used data structures for evaluating if:
  a. the app is ready (no callbacks to process)
  b. the component (or one if its children, for loading components) is awaiting the result of a callback
• remove connect from TreeContainer component
  a. Resolve loading_state in parent
  b. Resolve a loading state hash that can be used to decide if the parent needs to be re-rendered for its children
  c. Use context to provide shared data that do not affect re-renders (eg. graphs, etc.) - this replaces the connect usage

Companions
DCC: plotly/dash-core-components#810 (testing only)
Table: plotly/dash-table#785 (contains a tabe fix)
Docs: https://github.com/plotly/dash-docs/pull/888 (testing only)

There are some issues in the companion PRs but they seem related to CI only / the tests themselves are passing.

• Percy diff for table in dash-docs
  https://percy.io/plotly/dash-docs/builds/5455921/view/319601375/1280?mode=diff&browser=firefox&snapshot=319601375 (missing number of pages)

---

Performance

Gains increase as the number of displayed elements increases and can be explained by (1) less renders, (2) less expensive checks for states (eg. is_loading, shouldComponentUpdate).

1. dash.plotly.com/ vs branch (few components, none heavy, no callbacks)
   JS time: 625ms vs 592ms (20 runs, p=0.08)
   Total time: 1198ms vs 888ms (20 runs, p<=0.001)

2. dash.plotly.com/datatable/interactivity (few components, heavy: table/graph, w/ callbacks)
   No significant difference after 10 runs.
   JS time: 2488ms vs 2435ms (10 runs, p ~ 0.70)
   Total time: 3430ms vs 3369ms (10 runs, p ~ 0.70)

3. HTML Table with 1000 rows (dev vs. branch) (lots of lightweight components, no callbacks)
   JS time: 2706ms vs 1072ms (5 runs, p<=0.001)
   Total time: 3460ms vs 1817ms (5 runs, p<=0.001)

4. HTML Table with 5000 rows (dev vs. branch) (lots of lightweight components, no callbacks)
   JS time: 8412ms vs 3835ms (5 runs, p<=0.001)
   Total time: N/A, devtools terminated test too early for dev and numbers were no significant - JS times were obtained by starting/ending the tests manually

[Marc-Andre-Rivet]

@alexcjohnson

Would it be worth 🔒 that a little tighter by asserting the correct number of callback invocations in one or two of the existing wildcard tests?

be36ab4

Also, redux_state_rqs now supports both legacy and current implementation for Dash matrix testing with afcdba9 and 63f14af

[alexcjohnson]

Fantastic, I think you've got it! 💃

[Marc-Andre-Rivet]

Part of a larger performance rework. This PR proposes to break up the callback chain into smaller constituents by rewriting it using (1) a state-machine model where callbacks transition through various states (eg. requested, prioritized, executing, watched, executed, stored) that offer more limited logic each step of the way and hopefully easier optimization paths. (2) by handling derived store props and state transitions in (1) through the use of store observers.

• remove pendingCallbacks from the store and replace it with more easily used data structures for evaluating if:
  a. the app is ready (no callbacks to process)
  b. the component (or one if its children, for loading components) is awaiting the result of a callback
• remove connect from TreeContainer component
  a. Resolve loading_state in parent
  b. Resolve a loading state hash that can be used to decide if the parent needs to be re-rendered for its children
  c. Use context to provide shared data that do not affect re-renders (eg. graphs, etc.) - this replaces the connect usage

Companions
DCC: plotly/dash-core-components#810 (testing only)
Table: plotly/dash-table#785 (contains a tabe fix)
Docs: https://github.com/plotly/dash-docs/pull/888 (testing only)

There are some issues in the companion PRs but they seem related to CI only / the tests themselves are passing.

• Percy diff for table in dash-docs
  https://percy.io/plotly/dash-docs/builds/5455921/view/319601375/1280?mode=diff&browser=firefox&snapshot=319601375 (missing number of pages)

---

Performance

Gains increase as the number of displayed elements increases and can be explained by (1) less renders, (2) less expensive checks for states (eg. is_loading, shouldComponentUpdate).

1. dash.plotly.com/ vs branch (few components, none heavy, no callbacks)
   JS time: 625ms vs 592ms (20 runs, p=0.08)
   Total time: 1198ms vs 888ms (20 runs, p<=0.001)

2. dash.plotly.com/datatable/interactivity (few components, heavy: table/graph, w/ callbacks)
   No significant difference after 10 runs.
   JS time: 2488ms vs 2435ms (10 runs, p ~ 0.70)
   Total time: 3430ms vs 3369ms (10 runs, p ~ 0.70)

3. HTML Table with 1000 rows (dev vs. branch) (lots of lightweight components, no callbacks)
   JS time: 2706ms vs 1072ms (5 runs, p<=0.001)
   Total time: 3460ms vs 1817ms (5 runs, p<=0.001)

4. HTML Table with 5000 rows (dev vs. branch) (lots of lightweight components, no callbacks)
   JS time: 8412ms vs 3835ms (5 runs, p<=0.001)
   Total time: N/A, devtools terminated test too early for dev and numbers were no significant - JS times were obtained by starting/ending the tests manually

[Marc-Andre-Rivet]

@alexcjohnson

Would it be worth 🔒 that a little tighter by asserting the correct number of callback invocations in one or two of the existing wildcard tests?

be36ab4

Also, redux_state_rqs now supports both legacy and current implementation for Dash matrix testing with afcdba9 and 63f14af

[alexcjohnson]

Fantastic, I think you've got it! 💃

[Marc-Andre-Rivet]

Part of a larger performance rework. This PR proposes to break up the callback chain into smaller constituents by rewriting it using (1) a state-machine model where callbacks transition through various states (eg. requested, prioritized, executing, watched, executed, stored) that offer more limited logic each step of the way and hopefully easier optimization paths. (2) by handling derived store props and state transitions in (1) through the use of store observers.

• remove pendingCallbacks from the store and replace it with more easily used data structures for evaluating if:
  a. the app is ready (no callbacks to process)
  b. the component (or one if its children, for loading components) is awaiting the result of a callback
• remove connect from TreeContainer component
  a. Resolve loading_state in parent
  b. Resolve a loading state hash that can be used to decide if the parent needs to be re-rendered for its children
  c. Use context to provide shared data that do not affect re-renders (eg. graphs, etc.) - this replaces the connect usage

Companions
DCC: plotly/dash-core-components#810 (testing only)
Table: plotly/dash-table#785 (contains a tabe fix)
Docs: https://github.com/plotly/dash-docs/pull/888 (testing only)

There are some issues in the companion PRs but they seem related to CI only / the tests themselves are passing.

• Percy diff for table in dash-docs
  https://percy.io/plotly/dash-docs/builds/5455921/view/319601375/1280?mode=diff&browser=firefox&snapshot=319601375 (missing number of pages)

---

Performance

Gains increase as the number of displayed elements increases and can be explained by (1) less renders, (2) less expensive checks for states (eg. is_loading, shouldComponentUpdate).

1. dash.plotly.com/ vs branch (few components, none heavy, no callbacks)
   JS time: 625ms vs 592ms (20 runs, p=0.08)
   Total time: 1198ms vs 888ms (20 runs, p<=0.001)

2. dash.plotly.com/datatable/interactivity (few components, heavy: table/graph, w/ callbacks)
   No significant difference after 10 runs.
   JS time: 2488ms vs 2435ms (10 runs, p ~ 0.70)
   Total time: 3430ms vs 3369ms (10 runs, p ~ 0.70)

3. HTML Table with 1000 rows (dev vs. branch) (lots of lightweight components, no callbacks)
   JS time: 2706ms vs 1072ms (5 runs, p<=0.001)
   Total time: 3460ms vs 1817ms (5 runs, p<=0.001)

4. HTML Table with 5000 rows (dev vs. branch) (lots of lightweight components, no callbacks)
   JS time: 8412ms vs 3835ms (5 runs, p<=0.001)
   Total time: N/A, devtools terminated test too early for dev and numbers were no significant - JS times were obtained by starting/ending the tests manually

[Marc-Andre-Rivet]

@alexcjohnson

Would it be worth 🔒 that a little tighter by asserting the correct number of callback invocations in one or two of the existing wildcard tests?

be36ab4

Also, redux_state_rqs now supports both legacy and current implementation for Dash matrix testing with afcdba9 and 63f14af

[alexcjohnson]

Fantastic, I think you've got it! 💃

[Marc-Andre-Rivet]

Part of a larger performance rework. This PR proposes to break up the callback chain into smaller constituents by rewriting it using (1) a state-machine model where callbacks transition through various states (eg. requested, prioritized, executing, watched, executed, stored) that offer more limited logic each step of the way and hopefully easier optimization paths. (2) by handling derived store props and state transitions in (1) through the use of store observers.

• remove pendingCallbacks from the store and replace it with more easily used data structures for evaluating if:
  a. the app is ready (no callbacks to process)
  b. the component (or one if its children, for loading components) is awaiting the result of a callback
• remove connect from TreeContainer component
  a. Resolve loading_state in parent
  b. Resolve a loading state hash that can be used to decide if the parent needs to be re-rendered for its children
  c. Use context to provide shared data that do not affect re-renders (eg. graphs, etc.) - this replaces the connect usage

Companions
DCC: plotly/dash-core-components#810 (testing only)
Table: plotly/dash-table#785 (contains a tabe fix)
Docs: https://github.com/plotly/dash-docs/pull/888 (testing only)

There are some issues in the companion PRs but they seem related to CI only / the tests themselves are passing.

• Percy diff for table in dash-docs
  https://percy.io/plotly/dash-docs/builds/5455921/view/319601375/1280?mode=diff&browser=firefox&snapshot=319601375 (missing number of pages)

---

Performance

Gains increase as the number of displayed elements increases and can be explained by (1) less renders, (2) less expensive checks for states (eg. is_loading, shouldComponentUpdate).

1. dash.plotly.com/ vs branch (few components, none heavy, no callbacks)
   JS time: 625ms vs 592ms (20 runs, p=0.08)
   Total time: 1198ms vs 888ms (20 runs, p<=0.001)

2. dash.plotly.com/datatable/interactivity (few components, heavy: table/graph, w/ callbacks)
   No significant difference after 10 runs.
   JS time: 2488ms vs 2435ms (10 runs, p ~ 0.70)
   Total time: 3430ms vs 3369ms (10 runs, p ~ 0.70)

3. HTML Table with 1000 rows (dev vs. branch) (lots of lightweight components, no callbacks)
   JS time: 2706ms vs 1072ms (5 runs, p<=0.001)
   Total time: 3460ms vs 1817ms (5 runs, p<=0.001)

4. HTML Table with 5000 rows (dev vs. branch) (lots of lightweight components, no callbacks)
   JS time: 8412ms vs 3835ms (5 runs, p<=0.001)
   Total time: N/A, devtools terminated test too early for dev and numbers were no significant - JS times were obtained by starting/ending the tests manually

[Marc-Andre-Rivet]

@alexcjohnson

Would it be worth 🔒 that a little tighter by asserting the correct number of callback invocations in one or two of the existing wildcard tests?

be36ab4

Also, redux_state_rqs now supports both legacy and current implementation for Dash matrix testing with afcdba9 and 63f14af

[alexcjohnson]

Fantastic, I think you've got it! 💃