Looking at textarea-edit

Kentaro Hara

unread,

Sep 8, 2015, 10:13:35 PM9/8/15

to oilpan-...@chromium.org

Hi

I'm now looking at a regression in textarea-edit (assuming that fixing the perf issue in textarea-edit will fix other perf issues in Dromaeo etc). textarea-edit is regressing by 26%.

I minimized the test and created the following micro-benchmark:

<body>

function func() {

var textarea = document.createElement("textarea");

document.body.appendChild(textarea);

textarea.focus();

for (var i = 0; i < 300; ++i)

document.execCommand('insertText', false, 'a\n');

}

function log(time) {

document.getElementById("result").innerHTML += time + "<br>";

}

for (var j = 0; j < 30; ++j) {

var begin = performance.now();

func();

var end = performance.now();

log((end - begin).toFixed(2));

}

</script>

</body>

Results in non-oilpan:

194.82

193.63

184.17

183.60

184.36

185.01

185.69

192.09

184.73

185.38

185.35

186.75

187.31

187.81

159.50

146.71

144.88

146.78

144.74

145.22

145.34

146.66

145.97

146.51

147.69

146.73

148.22

147.86

190.80

190.26

Results in oilpan:

340.68

257.38

228.59

253.01

287.90

312.12

333.03

351.95

391.11

433.05

428.58

234.47

254.88

287.69

298.73

321.48

343.51

369.11

398.65

409.53

438.24

265.05

249.86

282.08

292.83

316.28

344.73

367.08

390.06

411.48

I confirmed the following things:

- Oilpan's GC happens only a couple of times. The time consumed in GCs doesn't explain the regression.

- textarea-edit.html creates a ton of persistent handles via FillLayer::m_image. However, I confirmed that the overhead of allocating/freeing persistent handles is not related to the regression.

Hmm.

--

Kentaro Hara, Tokyo, Japan

Kentaro Hara

unread,

Sep 9, 2015, 12:33:06 AM9/9/15

to oilpan-...@chromium.org

OK, now I identified the root cause. It is Document::m_ranges.

- textarea-edit.html allocates a lot of Ranges. They are registered to Document::m_ranges, which is a hash set of weak members.

- Most of the Ranges die shortly.

- However, with oilpan, those Ranges are not unregistered from the Document::m_ranges until the next GC hits.

- When doing layout (or something), we need to iterate the Document::m_ranges. The iteration becomes slower and slower until the next GC unregisters the Ranges from the Document::m_ranges. This causes the performance regression.

It seems that this is the main cause of the following regressions:

14% regression in div-editable.html

13% regression in textarea-dom.html

26% regression in textarea-edit.html

I think we can fix the regression by replacing problematic Range objects with EphemeralRanges (https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/editing/EphemeralRange.h&q=ephemeralrange&sq=package:chromium&type=cs&l=38), but I haven't yet studied what the problematic Range objects are. Maybe it would make more sense to just unship Oilpan from Ranges (maybe this is a bad idea since it will increase the number of persistent handles).

Would anyone have a bandwidth to take a look at this?

(I'll investigate other regressions in Dromaeo.)

Sigbjorn Finne

unread,

Sep 9, 2015, 2:07:47 AM9/9/15

to Kentaro Hara, oilpan-...@chromium.org

Den 9/9/2015 06:32, Kentaro Hara skreiv:
> OK, now I identified the root cause. It is Document::m_ranges.
>
> - textarea-edit.html allocates a lot of Ranges. They are registered to
> Document::m_ranges, which is a hash set of weak members.
> - Most of the Ranges die shortly.
> - However, with oilpan, those Ranges are not unregistered from the
> Document::m_ranges until the next GC hits.
> - When doing layout (or something), we need to iterate the
> Document::m_ranges. The iteration becomes slower and slower until the
> next GC unregisters the Ranges from the Document::m_ranges. This causes
> the performance regression.
>
> It seems that this is the main cause of the following regressions:
>
> 14% regression in div-editable.html
> 13% regression in textarea-dom.html
> 26% regression in textarea-edit.html
>
> I think we can fix the regression by replacing problematic Range objects
> with EphemeralRanges
> (https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/editing/EphemeralRange.h&q=ephemeralrange&sq=package:chromium&type=cs&l=38),
> but I haven't yet studied what the problematic Range objects are. Maybe
> it would make more sense to just unship Oilpan from Ranges (maybe this
> is a bad idea since it will increase the number of persistent handles).
>
> Would anyone have a bandwidth to take a look at this?
>

I can have a look wrt Range usage (this is with chrome, not content_shell?)

--sigbjorn

Kentaro Hara

unread,

Sep 9, 2015, 2:59:51 AM9/9/15

to Sigbjorn Finne, oilpan-...@chromium.org

Thanks!

Yes.

The test file attached to this email might expose the perf regression more clearly.

textarea-edit.html

Mads Sig Ager

unread,

Sep 9, 2015, 3:01:37 AM9/9/15

to Kentaro Hara, Sigbjorn Finne, oilpan-...@chromium.org

And here is the bug report with the work that has already gone into removing temporary Range objects: https://code.google.com/p/chromium/issues/detail?id=388681

I did some and it looks like yosin has been doing more recently.

Cheers,

Mads

Kentaro Hara

unread,

Sep 9, 2015, 3:04:30 AM9/9/15

to Mads Sig Ager, Sigbjorn Finne, oilpan-...@chromium.org

(BTW, thanks for still keeping your eyes on oilpan! :-)

Sigbjorn Finne

unread,

Sep 9, 2015, 3:22:20 AM9/9/15

to Kentaro Hara, oilpan-...@chromium.org

Den 9/9/2015 04:13, Kentaro Hara skreiv:
> Hi
>
> I'm now looking at a regression in textarea-edit (assuming that fixing
> the perf issue in textarea-edit will fix other perf issues in Dromaeo
> etc). textarea-edit is regressing by 26%.
>

Regression-wise, this is no worse than it has been earlier for
textarea-edit, right?

(cf.
https://aef6e225fbf3eabf04ab37cea7bc6fd8766d0e78-www.googledrive.com/host/0B6XhrzUCq5lhUjloNWR3b0xxRXM/2015/desktop-perf-188108/microbench.html
)

--sigbjorn

Kentaro Hara

unread,

Sep 9, 2015, 4:01:30 AM9/9/15

to Sigbjorn Finne, oilpan-...@chromium.org

Yes, this has been a long-standing regression. In the last final performance report, we ignored the regression because the behavior of textarea-edit.html in mobile devices were very flaky. I now realized that this is a real regression.

Sigbjorn Finne

unread,

Sep 9, 2015, 6:03:51 AM9/9/15

to Kentaro Hara, oilpan-...@chromium.org

Den 9/9/2015 10:00, Kentaro Hara skreiv:
> Yes, this has been a long-standing regression. In the last final
> performance report, we ignored the regression because the behavior of
> textarea-edit.html in mobile devices were very flaky. I now realized
> that this is a real regression.
>

I've found some places where EphemeralRange can be used with benefit,
but more sources of Range allocations needs to be looked at & rewritten
to address this one (wrt Range, at least.) Spellchecking is a source of
them.

--sigbjorn

Kentaro Hara

unread,

Sep 9, 2015, 7:10:41 AM9/9/15

to Sigbjorn Finne, oilpan-...@chromium.org

On Wed, Sep 9, 2015 at 7:03 PM, Sigbjorn Finne <s...@opera.com> wrote:

Den 9/9/2015 10:00, Kentaro Hara skreiv:

Yes, this has been a long-standing regression. In the last final
performance report, we ignored the regression because the behavior of
textarea-edit.html in mobile devices were very flaky. I now realized
that this is a real regression.

I've found some places where EphemeralRange can be used with benefit, but more sources of Range allocations needs to be looked at & rewritten to address this one (wrt Range, at least.) Spellchecking is a source of them.

Thanks!

Maybe this is not an option but there is also an option to unship oilpan from Ranges. It will end up with adding persistent handles to the Ranges. I'm not sure about the performance impact.

--sigbjorn

On Wed, Sep 9, 2015 at 4:22 PM, Sigbjorn Finne <s...@opera.com
<mailto:s...@opera.com>> wrote:

Den 9/9/2015 04:13, Kentaro Hara skreiv:

Hi

I'm now looking at a regression in textarea-edit (assuming that
fixing
the perf issue in textarea-edit will fix other perf issues in
Dromaeo
etc). textarea-edit is regressing by 26%.

Regression-wise, this is no worse than it has been earlier for
textarea-edit, right?

(cf.
https://aef6e225fbf3eabf04ab37cea7bc6fd8766d0e78-www.googledrive.com/host/0B6XhrzUCq5lhUjloNWR3b0xxRXM/2015/desktop-perf-188108/microbench.html
)

--sigbjorn

--
Kentaro Hara, Tokyo, Japan

Sigbjorn Finne

unread,

Sep 9, 2015, 8:39:23 AM9/9/15

to Kentaro Hara, oilpan-...@chromium.org

Den 9/9/2015 13:10, Kentaro Hara skreiv:
> On Wed, Sep 9, 2015 at 7:03 PM, Sigbjorn Finne <s...@opera.com

> <mailto:s...@opera.com>> wrote:
>
> Den 9/9/2015 10:00, Kentaro Hara skreiv:
>
> Yes, this has been a long-standing regression. In the last final
> performance report, we ignored the regression because the
> behavior of
> textarea-edit.html in mobile devices were very flaky. I now realized
> that this is a real regression.
>
>
> I've found some places where EphemeralRange can be used with
> benefit, but more sources of Range allocations needs to be looked at
> & rewritten to address this one (wrt Range, at least.) Spellchecking
> is a source of them.
>
>
> Thanks!
>
> Maybe this is not an option but there is also an option to unship oilpan
> from Ranges. It will end up with adding persistent handles to the
> Ranges. I'm not sure about the performance impact.
>

No Range allocations are now being made locally for that reduced TC (and
textarea-edit), but the reduced TC is still getting bogged down as it
runs, so there is something else/more going on here. Not many GCs, I notice.

(I'll need to tidy up and test the spellchecker changes that switches
over to EphemeralRange, but the switch looks feasible.)

--sigbjorn

>
> --sigbjorn
>
>
>
> On Wed, Sep 9, 2015 at 4:22 PM, Sigbjorn Finne <s...@opera.com
> <mailto:s...@opera.com>

Sigbjorn Finne

unread,

Sep 9, 2015, 11:36:21 AM9/9/15

to Kentaro Hara, oilpan-...@chromium.org

https://codereview.chromium.org/1329253002/ has those changes.

chrome-linux reports a 12-13% regression wrt non-Oilpan trunk, which is
an improvement over the > 20% regression seen without. Building &
gathering numbers on Windows still.

--sigbjorn

Sigbjorn Finne

unread,

Sep 9, 2015, 4:21:42 PM9/9/15

to Kentaro Hara, oilpan-...@chromium.org

Going over the details again on Range allocations with chrome (_not_
content_shell) turned out to be useful -- chrome exercises the
spellchecking code differently. Which meant that Range objects were
being created still, and quite a few.

So as to avoid Document::m_ranges buildup, I added Range::dispose() &
used it where we know Range values are effectively garbage & no longer
referenced.

With that in place, Oilpan is 25-30% faster than non-Oilpan on
textarea-edit w/ the above CL.

If you want to take over the CL and modify it further so as to get it
faster onto trunk, then please do. We can't afford to lose time.

--sigbjorn

Kentaro Hara

unread,

Sep 9, 2015, 7:49:12 PM9/9/15

to Sigbjorn Finne, oilpan-...@chromium.org

Thanks, appreciate it. The CL looks good to me.

Reply all

Reply to author

Forward