Backing nodes #4569
Closed
Backing nodes #4569
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
📊 Tachometer Benchmark ResultsSummaryA summary of the benchmark results will show here once they finish. ResultsThe full results of your benchmarks will show here once they finish. |
|
Size Change: +1.09 kB (+1.8%) Total Size: 61.9 kB
ℹ️ View Unchanged
|
JoviDeCroock
force-pushed
the
backing-nodes
branch
from
8773821
to
3e0f256
Compare
JoviDeCroock
force-pushed
the
backing-nodes
branch
from
3e0f256
to
e70cd55
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Due to the bad performance characteristics of #4567 I wanted to start out by creating a backing nodes branch. This moves all of the properties incrementally over to a new overarching structure, the first commits basically try to uphold our status quo and incrementally move us over to the new backing-node structure.
The goal here is to hold no more reference to the freshly produced
vnodeand store all of the render flags oninternalrather thanComponentandvnode. This should enable us to makeComponenttree-shakeable as well as boost performance as we will have smaller GC's due to the small size of avnodeand its fleety nature. In the current Preact X we have long lived GC runs as thevnodestructure is large and still replaced with every rerender.Digging deeper through this, it feels like we should split up mount and patch as it complicates our diffing process not to do so. In the first render the internals
vnodewill be equal to the "new"vnodewhich means that we can hit bail cases in the patch-y mount diffing that we currently do. Will investigate deeper but it looks like we might need to take an initial perf hit when developing this, could very well be that the perf pentalty on the current PR is a booboo on my behalf.