On 2013/01/14 15:56:51, Yang wrote:
LGTM, but I got one comment.
https://codereview.chromium.org/11889007/diff/1/src/runtime.cc
File src/runtime.cc (right):
https://codereview.chromium.org/11889007/diff/1/src/runtime.cc#newcode5910
src/runtime.cc:5910: if ((or_acc & kAsciiMask) != 0) {
Would it be noticeably more expensive to do this check for every word
instead
of
accumulating the words (bitwise-and, compare and jump as opposed to
bitwise-or)?
The tradeoff is that we can terminate early for the non-ascii case.
https://codereview.chromium.org/11889007/diff/1/src/runtime.cc#newcode6001
src/runtime.cc:6001: if (is_ascii) {
It looks like we could save time if Convert failed early if the result is
not
ascii.
I wrote a micro-benchmark for demonstration:
var a = "a";
for (var i = 0; i < 14; i++) a += a;
function test(str) {
var start = new Date();
for (var i = 0; i < 10000; i++) str.toUpperCase();
var mid = new Date();
for (var i = 0; i < 10000; i++) str.toLowerCase();
var end = new Date();
print("toUpper: " + (mid - start) + "\t toLower: " + (end - start));
}
test(a + "ö");
test(a + "ö" + a);
test("ö" + a);
Without ENABLE_LATIN_1, we get (on ia32)
toUpper: 629 toLower: 690
toUpper: 1256 toLower: 1379
toUpper: 629 toLower: 691
With ENABLE_LATIN1, we get
toUpper: 679 toLower: 796
toUpper: 1350 toLower: 1586
toUpper: 677 toLower: 795
With ENABLE_LATIN1 and early fail (such as "if ((w & kAsciiMask) != 0)
return
toUpper: 657 toLower: 793
toUpper: 1250 toLower: 1536
toUpper: 597 toLower: 743
It seems like testing each word for the ascii mask and failing early is not
more
expensive than accumulating and checking late. The same can be observed on
x64,
but the difference is somewhat smaller.
Unfortunately, a Nexus S (ARM) suffers visibly from early fail:
no early fail:
toUpper: 7438 toLower: 7279
toUpper: 14809 toLower: 14472
toUpper: 7422 toLower: 7269
early fail:
toUpper: 9380 toLower: 9392
toUpper: 15240 toLower: 15149
toUpper: 6228 toLower: 6058
Interestingly - on Intel architectures (my workstation) - if the input
string is
all lower case, toUpper is visibly faster than toLower. If the input string
is
all upper case, I observe the exact opposite. Apparently it's faster to use
the
changed string. The opposite is the case on the Nexus S.
https://codereview.chromium.org/11889007/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
