WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
101421
StringBuilder::append(UChar) with an 8 bit quantity shouldn't change the contents to 16 bits
https://bugs.webkit.org/show_bug.cgi?id=101421
Summary
StringBuilder::append(UChar) with an 8 bit quantity shouldn't change the cont...
Michael Saboff
Reported
2012-11-06 19:12:56 PST
StringBuilder objects keep track of whether or not the contents are all 8 bit in m_is8Bit. If appendChar(UChar) is called, m_is8Bit is set to false. An improvement is to look at the argument to StringBuilder::append(UChar) when m_is8Bit is true and see if the value can fit in 8 bits. If so, keep m_is8Bit true and append the character to the 8 bit buffer.
Attachments
Patch
(2.49 KB, patch)
2012-11-06 22:14 PST
,
Michael Saboff
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Michael Saboff
Comment 1
2012-11-06 22:14:07 PST
Created
attachment 172720
[details]
Patch This appears to be a progression on most of the Parser performance tests. Here is a comparison of the arithmetic average of 8 test runs for the parser tests: Test Baseline With Patch Change html-parser 2026.46ms 1989.21ms +2.8% html5-full-render 4274.28ms 4176.83ms +2.3% innerHTML-setter 263.14runs/s 269.21runs/s +2.3% simple-url 48.47runs/s 51.14runs/s +5.5% textarea-parsing 82.73runs/s 83.00runs/s +0.3% tiny-inner-HTML 5.08runs/s 5.07runs/s -0.2% url-parser 111.32runs/r 117.61runs/s +5.7% xml-parser 7.07runs/s 7.20runs/s +1.8%
WebKit Review Bot
Comment 2
2012-11-06 23:13:48 PST
Comment on
attachment 172720
[details]
Patch Clearing flags on attachment: 172720 Committed
r133726
: <
http://trac.webkit.org/changeset/133726
>
WebKit Review Bot
Comment 3
2012-11-06 23:13:51 PST
All reviewed patches have been landed. Closing bug.
Darin Adler
Comment 4
2012-11-07 08:48:56 PST
Comment on
attachment 172720
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=172720&action=review
> Source/WTF/wtf/text/StringBuilder.cpp:251 > + if (length == 1 && !(*characters & ~0xff)) { > + // Append as 8 bit character > + LChar lChar = static_cast<LChar>(*characters); > + append(&lChar, 1); > + return; > + }
It seems a little strange to have the 1-character special case here instead of in the append(UChar) function.
Darin Adler
Comment 5
2012-11-07 10:08:49 PST
Comment on
attachment 172720
[details]
Patch Now that I have some time to think about it, I realize I would have done this differently. I would have left the StringBuilder::append(const UChar, unsigned) function alone. And I would have added this to the start of append(UChar c): if (!(c & ~0xff)) { append(static_cast<LChar>(c)); return; } I wonder whether that version of the patch would have better or worse performance than the one you landed?
Michael Saboff
Comment 6
2012-11-07 15:28:18 PST
(In reply to
comment #5
)
> (From update of
attachment 172720
[details]
) > Now that I have some time to think about it, I realize I would have done this differently. I would have left the StringBuilder::append(const UChar, unsigned) function alone. And I would have added this to the start of append(UChar c): > > if (!(c & ~0xff)) { > append(static_cast<LChar>(c)); > return; > } > > I wonder whether that version of the patch would have better or worse performance than the one you landed?
I'll try that out, measure performance and report. I suspect that it will be pretty close to equal. The reason I went the way I did was to reduce bloat due to a larger inlined function. Therefore I'll also check object size differences as well.
Ojan Vafai
Comment 7
2012-11-08 10:30:35 PST
It's hard to tell with all the noise, but it also looks like this was a ~11% improvement in setting style.
http://build.chromium.org/f/chromium/perf/mac-release-10.6-webkit-latest/dromaeo_jslibstyleprototype/report.html?rev=166663&graph=jslib_style_prototype_Prototype___setStyle__&trace=score&history=50
Ojan Vafai
Comment 8
2012-11-08 11:09:35 PST
Actually, it's an improvement on a bunch of the jquery benchmarks:
http://build.chromium.org/f/chromium/perf/mac-release-10.6-webkit-latest/dromaeo_jslibstylejquery/report.html?rev=166613&graph=jslib_style_jquery_jQuery___height___x10&trace=score&history=150
http://build.chromium.org/f/chromium/perf/mac-release-10.6-webkit-latest/dromaeo_jslibstylejquery/report.html?rev=166613&graph=jslib_style_jquery_jQuery___width___x10&trace=score&history=150
http://build.chromium.org/f/chromium/perf/mac-release-10.6-webkit-latest/dromaeo_jslibstylejquery/report.html?rev=166664&graph=jslib_style_jquery_jQuery___css_color__x100&trace=score&history=150
http://build.chromium.org/f/chromium/perf/mac-release-10.6-webkit-latest/dromaeo_jslibstylejquery/report.html?rev=166664&graph=jslib_style_jquery_jQuery____is__visible_&trace=score&history=150
Probably some others too, but I'll stop there. :)
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug