render: fix perf regression introduced by #1918

[pygy]

I wanted to make sure that the changes I'm making to updateNodes don't have a negative impact on benchmarks and noticed a stark perf regression in the next branch when compared to v1.1.6. It turns out that checking parentNode happens to be toxic. Since #1916 was about select/option, I've limited the check to option elements.

How Has This Been Tested?

as little as #1918 since the mocks still don't support the correct API.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have updated docs/change-log.md

[pygy]

@robinchew does this look correct to you?

[tivac]

Good catch!

[robinchew]

How do you check for performance regression?

[pygy]

We have a builtin npm run perf and I was actually using https://github.com/krausest/js-framework-benchmark. I duplicated the Mithril benchmark and made it depend on my local git version of Mithril rather than the NPM version. The README of the project explains how to do that.

I used git bisect to identify the problem commit.

From the branch HEAD:

git bisect start
git bisect bad # mark the current commit as bad
git bisect good v1.1.5 # mark the last known good commit

At that point, git bisect will have checked out the commit in the middle of the section you want to investigate.
Then build the benchmark app, run the benchmarks. If the results are fast, git bisect good otherwise, git bisect bad. That will mark the current commit accordingly, and once again checkout the commit in the midddle of the unknown section.

HEAD // bad
-1
-2
-3
-4 <== test here... it's fast
-5
-6
-7 //good

Mark -4 ad good: git bisect good

HEAD // bad
-1
-2 // test here... it's slow
-3
-4 // good
-5
-6
-7 //good

Mark -2 as bad: git bisect bad

HEAD // bad
-1
-2 // bad
-3 // test here
-4 // good
-5
-6
-7 //good

Repeat until you've identified the first bad commit. Git bisect automatically moves the cursor for you.

I focused on the worse regression because running the benchmarks reliably requires me to exit every program and leave the computer alone. It turns out there are other problems.

I'm not faulting you here BTW @robinchew, your PR passed review. I didn't expect such a simple access to be that expensive.