Do not create a temporary Range object on updating spell checking markers.

Do not create a temporary Range object on updating spell checking markers.

As these markers are conditionally updated on every edit operation,
avoid creating a temporary Range object when doing so. With Oilpan
enabled, this avoids creating a GCed object that is only delay'edly
released.

Improves Oilpan performance on blink_perf.dom.textarea-edit by 10%.

R=haraken
BUG=388681
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=187820

[sof, 2015-01-02 09:16:15]

sigbjornf@opera.com changed reviewers:
+ oilpan-reviews@chromium.org, yosin@chromium.org

[sof, 2015-01-02 09:16:16]

Please take a look.

Rounding out the good work in https://codereview.chromium.org/576073003/ ,
making dom.textarea-edit really not allocate any Range objects.

For that test, this puts Oilpan ahead by 2-3% when testing locally (linux64.) As
expected, it brings no measurable performance benefits with Oilpan disabled.

[haraken, 2015-01-02 16:46:52]

LGTM

[sof, 2015-01-02 17:24:38]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2015-01-02 17:25:01]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/828293002/1

[commit-bot: I haz the power, 2015-01-02 18:42:51]

Committed patchset #1 (id:1) as
https://src.chromium.org/viewvc/blink?view=rev&revision=187820

[haraken, 2015-01-03 08:14:28]

BTW, how did you come up with this optimization? I'm wondering how you find
short-lived objects that should be deoilpanized. I guess there would be a bunch
of other places where we can improve performance by deoilpanizing something.

[sof, 2015-01-03 08:52:47]

On 2015/01/03 08:14:28, haraken wrote:
> BTW, how did you come up with this optimization? I'm wondering how you find
> short-lived objects that should be deoilpanized. I guess there would be a
bunch
> of other places where we can improve performance by deoilpanizing something. 

updateMarkersForWordsAffectedByEditing() came up when profiling
textarea-edit.html, which made me look at the code. The short-lived Range
allocation in there reminded me of ager's previous work, so just took it from
there. i.e., that the codebase makes use of short-lived Range objects had been
uncovered previously.

Knowing if there are objects with high mortality rates would be one indirect
indicator of short-lived objects, but doesn't pinpoint their source(s) in any
way. Interesting question.