Quick question: how is memory usage impacted? Sparse arrays take more memory than equivalent-length dense arrays, so I just want a quick sanity check here on its implications.

Also, how does it compare to an explicit children.push(Vnode.normalize(vnode.children[i]))?

@dead-claudia Thank you for your review.

I briefly verified the followings.

how is memory usage impacted?

I logged process.memoryUsage() in onCycle during npm run perf. Because the results varied each run, I couldn’t tell whether there was any real difference between versions.
(I usually benchmark by npm run perf for speed only, so I don’t have much experience with memory consumption benchmarks. If you can suggest a specific method, I’d be grateful.)

Also, how does it compare to an explicit children.push(Vnode.normalize(vnode.children[i]))?

If the push variant performed as well as this PR, I would favor it, but that doesn’t seem to be so.
I tried the following variants, but none of them achieved speeds comparable to this PR.

// (1) About the same performance as v2.3.7
var children = []
var numKeyed = 0
for (var i = 0; i < input.length; i++) {
	children.push(Vnode.normalize(input[i]))
	if (children[i] != null && children[i].key != null) numKeyed++
}

// (2) It is slightly faster than v2.3.7, but it is not as good as this PR.
var children = []
var numKeyed = 0
var normalized
for (var i = 0; i < input.length; i++) {
	children.push(normalized = Vnode.normalize(input[i]))
	if (normalized != null && normalized.key != null) numKeyed++
}

// (3) Almost the same performance as (2)
var children = []
var numKeyed = 0
for (var i = 0; i < input.length; i++) {
	var normalized = Vnode.normalize(input[i])
	children.push(normalized) 
	if (normalized != null && normalized.key != null) numKeyed++
}

(I usually benchmark by npm run perf for speed only, so I don’t have much experience with memory consumption benchmarks. If you can suggest a specific method, I’d be grateful.)

@kfule Spin up a local server from the repo root, open /performance/index.html in a Chromium browser, open the dev tools, and take a couple heap snapshots. From there, you can compare snapshots to see what all was newly allocated between runs, and that'll help you find the vnodes.

If you use Firefox, the process is similar, just with stuff in different locations.

@dead-claudia
Thanks for your advice!
I tried looking for vnodes in the DevTools memory pane on my Edge (one of the Chromium browsers).

For clarity, I assigned the following vnode to this.largeVnodes and searched for it.
(I did this because this.cached is easier to find in the "rerender identical vnode", and I wanted to check a large vnode.)

// I assigned the vnode to `largeVnodes` like this
this.largeVnodes = m(".foo.bar[data-foo=bar]", {p: 2},

The screenshots of the results from the two branches (main (v2.3.7 mithril.js bundle) and this PR build bundle) are as follows. While they are indeed running different mithril.js scripts, they appear to show no differences.

current main branch (v2.3.7)

this PR

Additionally, there were largeVnodes within _original as well, and this PR appears to have lower memory consumption.

current main branch (v2.3.7)

this PR

These do appear to capture the vnode results, but since I'm unfamiliar with this, there might be other areas I should be looking at.

Also, this PR might have an advantage since reallocation disappears with large arrays, though.

A long time ago, V8 used to always allocate new Array(len) as sparse, so I was a bit skeptical of the benefit at first. I did some digging, and this appears to have changed, and it changed longer ago than I thought.

@dead-claudia
Thank you for your review comments. I tried running npm run perf, and the current version of !== seems slightly better.
Personally, since the bundle size doesn't seem to change much either, I think the current version with its good readability is good enough.