New issue
Advanced search Search tips

Issue 844093 link

Starred by 11 users

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Setting textContent should be faster than setting innerText

Project Member Reported by jasonjmi...@chromium.org, May 17 2018

Issue description

Chrome Version: 66.0.3359.170 (Official Build) (64-bit)
OS: MacOS 10.13.3

What steps will reproduce the problem?
(1) Run benchmark: https://esbench.com/bench/590c9cfe99634800a0347ffc
(2) Observe setting textContent is slower than nodeValue

What is the expected result?
Setting Node.prototype.textContent should be faster than Node.prototype.innerText, since the latter has additional behaviors described here: https://github.com/w3c/web-platform-tests/blob/e078010b4a0dc252fccac8ce7436403d66ff31de/innerText/setter-tests.js

What happens instead?
Setting textContent is slower.

Please use labels and text to provide additional information.

If this is a regression (i.e., worked before), please consider using the
bisect tool (https://www.chromium.org/developers/bisect-builds-py) to help
us identify the root cause and more rapidly triage the issue.

For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.


 
Summary: Setting textContent should be faster than setting innerText (was: Setting textContent should be faster than setting nodeValue)
Components: -Blink>Bindings
A quick skim: looks to me like we have an unsound optimization (that's we've kept) in innerText where we reuse the existing text node if it exists, whereas nodeValue does what the spec says and reuses the existing Text node and simply adjusts its value.

The spec says we should do the slow thing in both cases:
https://dom.spec.whatwg.org/#dom-node-textcontent
https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute

This is web-observable (you can tell the difference with a mutation observer, for instance). I'm not sure it's wise to either propagate this trick more, or to roll it back (taking a regression on the fast version), but DOM folks may have opinions.

Agreed it's unintuitive. FWIW, if you know this is what your content is doing, you can of course set the nodeValue on the Text node itself, which as your benchmark shows is faster than both.
Thanks @jbroman - just a note for others, here's some additional context:
https://twitter.com/_developit/status/997132016612270081

Comment 4 by fergal@chromium.org, May 31 2018

Status: Available (was: Untriaged)

Sign in to add a comment