Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve entropy recalculations #1879

Merged
merged 5 commits into from
Nov 5, 2024

Conversation

jameshadfield
Copy link
Member

Improves the general speed of Auspice when the Entropy panel is not displayed (either toggled off or off-screen). The downside is a small amount of time where there's a blank entropy panel when it scrolls back into view after a state change which requires the entropy data to be recalculated. (The win is that we skip these recalculations so everything else is faster.)

Eyes on the behaviour changes in this PR would be very welcome!

There's more we can do here, but I'll leave the following for subsequent PRs:

  • I'd like to investigate shifting the entire recalculation off to a worker thread. The mutation data can be transferred once (it never changes) so I think the IO should be fast.
  • I suspect the slowness is the myriad string slice operations - how much faster would it be to pre-process these and store as arrays. (And how much more memory would this take?)
  • The debouncing could be smarter, perhaps utilising the requestIdleCallback API

Related to #1878

@jameshadfield
Copy link
Member Author

Updated to fix a bug when viewing narratives and also fix linting errors

Copy link
Contributor

@joverlee521 joverlee521 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I played around with the groups/blab/ncov-orf8ko/WA/20k dataset and definitely see improvements in responsiveness!

I only left non-blocking comments. In general, I find the split of management of entropy data between the Redux actions and Entropy component a bit weird. It feels like the Redux actions should trigger that entropy data updates appropriately and the Entropy component should just remain a consumer of that data.

src/components/entropy/index.js Outdated Show resolved Hide resolved
src/components/entropy/index.js Outdated Show resolved Hide resolved
src/components/entropy/index.js Outdated Show resolved Hide resolved
@jameshadfield jameshadfield force-pushed the james/improve-entropy-recalculations branch 2 times, most recently from 65a982c to 446d5c9 Compare November 5, 2024 00:24
jameshadfield added a commit that referenced this pull request Nov 5, 2024
by not recalculating data on the leading edge of the debounced
recalculation action. For big trees (which take >500ms of time to
redraw) the main thread is still blocked for roughly the same amount of
time, but the tree is redrawn faster. For small trees which redraw
quicker than that the entropy doesn't update until the debounce 500ms
timeout is reached, resulting in slightly odd behaviour.

(Reducing this timout also results in less-than-ideal behaviour as
(e.g.) dragging the date range of a tree results in interruptions while
the entropy calcs run which is worse IMO.)
Improves the performance of most interactions in Auspice when the
`<Entropy>` panel's not displayed by not constantly updating the entropy
calculations. The downside is when the panel's toggled on things are a
little slower as we recalculate at that point.

Note that the Entropy panel should never be rendered with invalid /
stale / uncomputed data. Any action which results in the panel being
shown is responsible for ensuring the underlying data is updated as
appropriate.
Use an intersection observer to detect when the entropy panel is visible
on the screen (viewport). When it's offscreen we don't update entropy
data (an expensive calculation). When it comes back onscreen we
recalculate the entropy data if it has become stale.

This results in slightly strange behaviour when the entropy panel will
be shown with no bars and they'll be drawn after a slight delay (while
the data's recalculated). The wins are much improved performance when
the entropy panel is not on screen (which is common).
@jameshadfield jameshadfield force-pushed the james/improve-entropy-recalculations branch from 3799a98 to 5543a86 Compare November 5, 2024 20:54
@jameshadfield
Copy link
Member Author

Rebased onto master which now includes e3cfb27 as part of #1883. Merging.

@jameshadfield jameshadfield merged commit def2ffb into master Nov 5, 2024
26 checks passed
@jameshadfield jameshadfield deleted the james/improve-entropy-recalculations branch November 5, 2024 21:34
jameshadfield added a commit that referenced this pull request Nov 12, 2024
The bug arose because window-resizes trigger a complete re-render of
the entropy panel's SVG and this didn't correctly handle an edge case
where the entropy data was stale (a concept introduced in #1879).

For specific steps to reproduce see <#1895 (comment)>

Closes #1895
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants