perf: avoid using a stack in traverseAndSetElements

[nolanlawson]

Details

This improves the js-framework-benchmark's create-10k test by 8-10% in Chrome/Firefox and 4-9% in Safari. It does so by avoiding either recursion or a stack (array) by using a loop with firstChild/nextSibling/parentNode.

Click to see benchmark results

I was kind of concerned that adding parentNode would cause a perf regression in synthetic shadow (due to patches), but I tested manually in synthetic shadow (nolanlawson@4536c23), and it's faster there as well:

Click to see

I also tried using a TreeWalker (nolanlawson@303e7b7), since this is what Lit does. However, I found that the TreeWalker is ~0.5% slower than the loop:

Click to see

(TreeWalker is this-change, loop is tip-of-tree)

We may still want to consider the TreeWalker someday, due to the possible benefits in synthetic shadow (which does not patch TreeWalker at all), and because it's slightly less code.

One major downside, though, is that we'd need to implement a TreeWalker shim for @lwc/engine-server. For that reason, and because this is the optimal solution for js-framework-benchmark, I'm proposing this for now.

Does this pull request introduce a breaking change?

• 😮‍💨 No, it does not introduce a breaking change.

Does this pull request introduce an observable change?

• 🤞 No, it does not introduce an observable change.

[jye-sf]

This is really neat! It makes me wonder whether we can apply this to some of the other depth-first traversals we do in the engine (and/or whether those traversals are hot enough to warrant the effort).

[jye-sf]

Is there a specific situation you're thinking about that warrants this assertion, and should we have a test case for it?

[nolanlawson]

It's not really possible to hit, but I'm concerned we could recurse up past the root if (somehow) there were more parts to be found. This happened in the past when we messed up and forgot to include comment nodes when preserve-comments is on.

[nolanlawson]

It makes me wonder whether we can apply this to some of the other depth-first traversals we do in the engine (and/or whether those traversals are hot enough to warrant the effort).

Yep, another one is recursivelySetShadowResolver in synthetic-shadow. We could use this algorithm there too instead of using recursion.