Rakina, would you work on this?

CL for the specific case of innerHTML = '' is here crrev.com/c/813448.

It seems that Mozilla also optimizes for short strings without markups inside it and sets the length limit as 100 (searching for markup character is slow). We will do that in a separate CL, will compare performance between various length limits first.

Comparison between various length limits is here: https://docs.google.com/spreadsheets/d/1MJnSNUl6fSQgoGQtGcCOyAgP2u5rIuzBIGZ0TOW7m74/edit?usp=sharing

On speedometer, there aren't really a lot of difference between various length limits. I made a simple JS test here also: http://jsbin.com/yelahemisu/edit?html,console

On that test, innerHTML="" optimization (empty-string only optimization) speeds up the operation by 17x and makes almost every case faster except on strings with length >= 500, somehow. But they're all around 1-1.2x

When the change is only a few characters, all non-empty limit gives huge speedup (1 char string -> 5x speedup, 8 char string -> 8-9x speedup) but slows down by around 1.2x when the string has markup (fail to optimize)

When the limit is big (100, 500, infinite), changes of longer string with no markup (~100chars) experiences 4-5x speedup, but I'm not sure how often a long string with no markup will show up. It seems to peak around 100 chars, as the speedup on strings with no markup of length 500&1000 only sped up by around 2x.

If the string turns out to have markup, the slowdown is around 1.06x - 1.1x (I am not sure know how bad that is)

Anyone have any thoughts on this? I'm leaning towards a limit of >100.

Maybe this issue just reaches to those who follow this bug
(starred, owner of components, and the owner) - probably such discussion
could better happen at chromium-discuss@ or blink-dev@ to draw more
attention from those who are interested and get useful comments.

I started a discussion on blink-dev mailing list, and it seems the best way now is to only optimize for empty strings (innerHTML=''), but I will try to find a way to gather data round the short string optimization later.

Link to discussion: https://groups.google.com/a/chromium.org/d/msg/blink-dev/AUqsuLq70kA/YoM7iKD0AAAJ

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b413fb498a9d6588ab431f7fd5c42ea707add52e

commit b413fb498a9d6588ab431f7fd5c42ea707add52e
Author: Rakina Zata Amni <rakina@chromium.org>
Date: Thu Jan 18 04:05:47 2018

Add optimization on InnerHTML setter when new string is empty

It's pretty common for authors to do innerHTML = '' to remove all the
children of an element, but this invokes the parser and allocates a
DocumentFragment a bunch of other data structures. We could make this
much faster by noticing it's not a special element and just removing
all the children like textContent = null would.

This change adds a check in InnerHTML setter so that when the new
string for innerHTML is empty we can just update its TextContent
instead of making a DocumentFragment and other unnecessary stuff
for this case.

Bug:  785166 
Change-Id: I29aaead811e820e7b38528efc3bfa3cce5bf7bab
Reviewed-on: https://chromium-review.googlesource.com/813448
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Hayato Ito <hayato@chromium.org>
Reviewed-by: Kent Tamura <tkent@chromium.org>
Reviewed-by: Takayoshi Kochi <kochi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#530047}
[modify] https://crrev.com/b413fb498a9d6588ab431f7fd5c42ea707add52e/third_party/WebKit/Source/core/dom/Element.cpp
[modify] https://crrev.com/b413fb498a9d6588ab431f7fd5c42ea707add52e/third_party/WebKit/Source/core/dom/Element.h
[modify] https://crrev.com/b413fb498a9d6588ab431f7fd5c42ea707add52e/third_party/WebKit/Source/core/html/HTMLFrameSetElement.h
[modify] https://crrev.com/b413fb498a9d6588ab431f7fd5c42ea707add52e/third_party/WebKit/Source/core/html/HTMLHeadElement.h
[modify] https://crrev.com/b413fb498a9d6588ab431f7fd5c42ea707add52e/third_party/WebKit/Source/core/html/HTMLHtmlElement.h
[modify] https://crrev.com/b413fb498a9d6588ab431f7fd5c42ea707add52e/third_party/WebKit/Source/core/html/HTMLTableCaptionElement.h
[modify] https://crrev.com/b413fb498a9d6588ab431f7fd5c42ea707add52e/third_party/WebKit/Source/core/html/HTMLTableCellElement.h
[modify] https://crrev.com/b413fb498a9d6588ab431f7fd5c42ea707add52e/third_party/WebKit/Source/core/html/HTMLTableColElement.h
[modify] https://crrev.com/b413fb498a9d6588ab431f7fd5c42ea707add52e/third_party/WebKit/Source/core/html/HTMLTableElement.h
[modify] https://crrev.com/b413fb498a9d6588ab431f7fd5c42ea707add52e/third_party/WebKit/Source/core/html/HTMLTableRowElement.h
[modify] https://crrev.com/b413fb498a9d6588ab431f7fd5c42ea707add52e/third_party/WebKit/Source/core/html/HTMLTableSectionElement.h
[modify] https://crrev.com/b413fb498a9d6588ab431f7fd5c42ea707add52e/third_party/WebKit/Source/core/html/HTMLTemplateElement.h
[modify] https://crrev.com/b413fb498a9d6588ab431f7fd5c42ea707add52e/third_party/WebKit/Source/core/html/forms/HTMLSelectElement.h