feat: use longest increasing subsequence discovery to minimize DOM node moves - #5184
Open
jviide wants to merge 3 commits into
Open
feat: use longest increasing subsequence discovery to minimize DOM node moves#5184jviide wants to merge 3 commits into
jviide wants to merge 3 commits into
Conversation
📊 Tachometer Benchmark ResultsSummaryduration
usedJSHeapSize
Resultscreate10kduration
usedJSHeapSize
filter-listduration
usedJSHeapSize
hydrate1kduration
usedJSHeapSize
many-updatesduration
usedJSHeapSize
replace1kduration
usedJSHeapSize
run-warmup-0
run-warmup-1
run-warmup-2
run-warmup-3
run-warmup-4
run-final
text-updateduration
usedJSHeapSize
tododuration
usedJSHeapSize
update10th1kduration
usedJSHeapSize
|
jviide
force-pushed
the
manneken-lis
branch
2 times, most recently
from
July 29, 2026 23:35
c85b0f5 to
c86f509
Compare
|
coverage: 98.534%. remained the same — jviide:manneken-lis into preactjs:main |
jviide
force-pushed
the
manneken-lis
branch
2 times, most recently
from
July 30, 2026 18:51
d63b420 to
84c0d9a
Compare
Mirrors the edge-case coverage added to the v10.x displacement heuristic (preactjs#5172), where the minimal-move pass produces identical operation logs for every case: - a far swap moves only the two swapped children - displacing more than half the list moves the shorter suffix - displacement combined with an appended or removed child - three consecutive displacements to catch state accumulation issues - correctness of raw text siblings around displaced keyed children
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
This pull request is a take on the longest increasing subsequence (LIS) patience sort algorithm for determining which children are already in the correct relative order. See #5174 for an alternative implementation. The aim here is to also optimize implementation size by weaving the implementation into the
constructNewChildrenArraymain loop.Benchmarks against main and #5174 seems to show both LIS implementations performing similarly:
reorder1kupdate10th1kcreate10kmany-updatesThere are a couple of implementation trade-offs:
pilesarray for everydiffChildren()call. On the other hand avoids a separate per-index LIS tracking array by reusingVNode._depth.This change also frees the skew mechanism from the reponsibility of preserving relative node ordering (as LIS now always takes care of that), so there should be more leeway to experiment with the skew heuristics for node matching.
Total byte increase for
preact.mjs.brvs. the current main version: +53 B