-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Rework children diffing to run in multiple phases #4180
Conversation
📊 Tachometer Benchmark ResultsSummaryduration
usedJSHeapSize
Results02_replace1k
duration
usedJSHeapSize
run-warmup-0
run-warmup-1
run-warmup-2
run-warmup-3
run-warmup-4
run-final
03_update10th1k_x16
duration
usedJSHeapSize
07_create10k
duration
usedJSHeapSize
filter_list
duration
usedJSHeapSize
hydrate1k
duration
usedJSHeapSize
many_updates
duration
usedJSHeapSize
text_update
duration
usedJSHeapSize
todo
duration
usedJSHeapSize
|
Size Change: +511 B (0%) Total Size: 59.7 kB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks amazing, I have a follow up with the test in #4181
447fbfa
to
58001b4
Compare
…to constructNewChildrenArray (-27 B)
Will always be cleared in parent diffChildren or commitRoot
58001b4
to
5e5e387
Compare
Okay, I think I've figured out the performance slowdown in many_updates. It appears we have hit a perf cliff with the number of properties on VNode. I first tried some code reorganizations to see if it was a runtime difference (those experiments can be found on the To find the analysis tables shown below, go to the linked "Benchmark Debug" workflow run, view the logs for the "Bench many_updates" job, and expand the "Analyze logs if present" step. To view the trace timelines, download the Below are some screenshots from tracing and analyzing a commit from two-phase-diffChildren-2-deopts branch (before a rebase and before playing with the number of VNode fields). You can see the results yourself here: https://github.com/preactjs/preact/actions/runs/6739103123. ![]() ![]() ![]() ![]() ![]() ![]() The first thing I noticed from examining a sample trace timeline of Looking at the analysis tables also confirms some other changes related to GC. Notice how while the "Count of MinorGCs" is basically the same between the "preact-main" and "preact-local" (this branch), the amount of time spent in MinorGC ("Sum of MinorGC") is much larger. Also, the amount of heap used after a MinorGC ("MinorGC usedHeapSizeAfter") is much larger! even though after a MajorGC the usedHeapSize is basically the same (couple hundred kilobytes different). The biggest change to GC that I think this PR introduces is adding a field to VNode. So I tested again by removing the ![]() ![]() ![]() ![]() So I'm going to explore ways to perhaps reduce the number of VNode fields so fix this regression. I'm considering folding |
Removing internal only properties like |
08a277a
to
6eef30b
Compare
Co-authored-by: Jovi De Croock <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the code golf suggestions <3
The text_update regression makes me wonder whether it would be worth having a specialized path but not sure 😅 can look deeper after we merge |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the move to flags as well. Agree with Jovi that we can figure out why that particular benchmark regressed later.
Restart of #4162 on top of lastest main.
Rework children diffing to run in multiple phases:
A couple additional changes to highlight
placeChild
andreorderChildren
into a singleinsert
function & simplify insertion logic in diffChildrenFixes #4156