[Webkit-unassigned] [Bug 66286] Use String [] operator instead of indexing into String::characters() directly

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=66286





--- Comment #12 from Xianzhu Wang <wangxianzhu at chromium.org>  2011-08-17 21:28:01 PST ---
Created an attachment (id=104303)
 --> (https://bugs.webkit.org/attachment.cgi?id=104303&action=review)
performance test

I tested the performance with the attached program. To run it, you should have a chromium port of WebKit, put it under Source/WebKit/chromium/tests, and add it into Source/WebKit/chromium/WebKit.gypi, update and build webkit, then run 'out/Release/webkit_unit_tests --gtest_filter=StringTest.*'.

My results are:
accessStringPtr: 0.660000
accessStringPtrNoPostPlusPlus: 0.660000
accessCharacters: 0.650000
accessImpl: 0.650000
accessImplCacheLength: 0.660000
accessArray: 1.000000
accessArrayCacheLength: 1.000000

Description of the test:
Run 100000 times sequentially accessing each character of a string containing 10000 characters.
accessStringPtr: use a StringPtr class to simulate characters() and UChar*
accessStringPtrNoPostPlusPlus: same as above, but avoid using ptr++
accessCharacters: use characters()
accessImpl: use StringImpl instead of characters(); use length() in loop
accessImplCacheLength: same as above, but save length() to a local variable before loop
accessArray: use String::operator[]; use length() in loop
accessArrayCacheLength: same as above, but save length() to a local variable before loop

The timings show that the only performance difference is about the range checking in String::operator[]. If eliminating it, there would be no performance difference.

I think we could have two choices:
1. Add String::ptr() to return StringPtr class instead of UChar*, and replace some characters() references with it.
2. Replace the range checking in String::operator[] to an ASSERT. 

I have no preference and would like to hear your opinions.

About the performance cost of checking 8-bit or 16-bit, I will investigate it. However, it seems not in scope of this bug.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.