Improve the find word boundary performance

Improve the find word boundary performance

In endWordBoundary case, finding start boundary in findWordBoundary is unnecessary.
So, skip it to improve the find word boundary performance.

Merge from WebKit
https://bugs.webkit.org/show_bug.cgi?id=125619

BUG=371249
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=178621

[Kyungtae Kim, 2014-05-08 05:33:56]

PTAL

[eseidel, 2014-05-29 00:13:53]

This is a good change for eae, leviw or yoshi.

[eae, 2014-05-29 00:16:21]

Is there a test demonstrating the performance impact of this? I fear that the
extra branch might counter the performance advantage of not setting the start
boundary.

[yosin_UTC9, 2014-05-29 01:12:04]

Thanks for improving performance! I saw test case in WebKit bug repository, it
is 110K+ word.

How about having findStartOfWordBoundary() and findEndOfWordBoundary()? There
are only two call sites of findWordBoundry(), startWordBOundary() and
endWordBoundary()?

I know having two functions increase code size, but it is small.
They can be:

int findWordEndBoundary(const UChar* chars, int len int position) {
  TextBreakIterator* it = wordBreakIterator(chars, len);
  int end = it->following(position);
  return end < 0 ? it->last() : end;
}

int findWordStartBoundary(const UChar* chars, int len int position) {
  TextBreakIterator* it = wordBreakIterator(chars, len);
  it->following(position);
  return it->previous();
}

This can remove code for arguments passing of two |int| pointer and deref of
|int| points in function. Of course we need to measure actual code size.

(for me), above code is more easy to read, and function names represent
intention.

HDYT?

[Kyungtae Kim, 2014-07-21 02:35:03]

On 2014/05/29 01:12:04, Yosi_UTC9 wrote:
> Thanks for improving performance! I saw test case in WebKit bug repository, it
> is 110K+ word.
> 
> How about having findStartOfWordBoundary() and findEndOfWordBoundary()? There
> are only two call sites of findWordBoundry(), startWordBOundary() and
> endWordBoundary()?
> 
> I know having two functions increase code size, but it is small.
> They can be:
> 
> int findWordEndBoundary(const UChar* chars, int len int position) {
>   TextBreakIterator* it = wordBreakIterator(chars, len);
>   int end = it->following(position);
>   return end < 0 ? it->last() : end;
> }
> 
> int findWordStartBoundary(const UChar* chars, int len int position) {
>   TextBreakIterator* it = wordBreakIterator(chars, len);
>   it->following(position);
>   return it->previous();
> }
> 
> This can remove code for arguments passing of two |int| pointer and deref of
> |int| points in function. Of course we need to measure actual code size.
> 
> (for me), above code is more easy to read, and function names represent
> intention.
> 
> HDYT?

You're right.
For "end boundary", above code seems much better.
But I think general function for finding word boundary is still needed, and now
it's used by HTMLTextFormControlElement.cpp.
(https://codereview.chromium.org/357603003/)

So, I think just add findWordEndBoundary function can be a solution.
How do you think?

[yosin_UTC9, 2014-07-22 00:58:53]

LGTM
Please wait for OWNERS review for committing.

[eae, 2014-07-22 01:26:51]

LGTM

[Kyungtae Kim, 2014-07-22 02:45:39]

The CQ bit was checked by ktf.kim@samsung.com

[commit-bot: I haz the power, 2014-07-22 02:46:26]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ktf.kim@samsung.com/268363016/10001

[commit-bot: I haz the power, 2014-07-22 03:46:22]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  mac_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/mac_blink_rel/builds/16452)
  win_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/win_blink_rel/builds/18099)

[commit-bot: I haz the power, 2014-07-22 04:26:44]

Change committed as 178621