Hi,
I posted on gitter, and G+ with this issue, but it seems perhaps that this
is the correct place to post.
I noticed a significant performance regression when compiling my heavy GWT
application with 2.8.0-RC1. The slowdown was an order of magnitude slower
on Chrome 10x, on Firefox 3x, and on IE 2x.
I've been developing this application for a number of years, and it
involves client side parsing of text. It makes heavy use of generated code,
and therefore it uses a lot of string functions.
I've managed to use the *Chrome debugger *to narrow the location of the
regression down to the new 2.8.0 implementation of
"*java.lang.String.valueOf(char
data[], int offset, int count)*".
*2.7.0 - Baseline implementation*
Here is a partial implementation of *java.lang.String.valueOf(char data[],
int offset, int count) *in 2.7.0.
function *java_lang_String_valueOf___3CIILjava_lang_String_2*(x_0, offset,
count){
var end;
end = offset + count;
java_lang_String__1_1checkBounds__IIIV(x_0.length, offset, end);
return java_lang_String__1_1valueOf___3CIILjava_lang_String_2(x_0,
offset, end);
}
*2.8.0 RC1 - New Implementation - with regression*
function *java_lang_String_valueOf___3CIILjava_lang_String_2*(x_0, offset,
count){
java_lang_String_$clinit__V();
var batchEnd, batchStart, end, s;
end = offset + count;
javaemul_internal_InternalPreconditions_checkCriticalStringBounds__IIIV(offset,
end, x_0.length);
s = '';
for (batchStart = offset; batchStart < end;) {
batchEnd = batchStart + $intern_13 < end?batchStart + $intern_13:end;
s +=
java_lang_String_fromCharCode___3Ljava_lang_Object_2Ljava_lang_String_2(x_0.slice(batchStart,
batchEnd));
batchStart = batchEnd;
}
return s;
}
*My Fix*
My fix is to simply return the 2.7.0 implementation whist making use of the
new
'javaemul_internal_InternalPreconditions_checkCriticalStringBounds__IIIV'
method, and changing the order of the parameters versus the old
'java_lang_String__1_1checkBounds__IIIV' method. I also create a supporting
function that does not seem to be present in my 2.8.0 generated code:
function *java_lang_String_valueOf___3CIILjava_lang_String_2*(x_0, offset,
count){
var end;
end = offset + count;
javaemul_internal_InternalPreconditions_checkCriticalStringBounds__IIIV(offset,
end, x_0.length);
return java_lang_String__1_1valueOf___3CIILjava_lang_String_2(x_0,
offset, end);
}
// COPIED FROM 2.7.0
function *java_lang_String__1_1valueOf___3CIILjava_lang_String_2*(x_0,
start_0, end){
var s = '';
for (var batchStart = start_0; batchStart < end;) {
var batchEnd = Math.min(batchStart + 10000, end);
s += String.fromCharCode.apply(null, x_0.slice(batchStart, batchEnd));
batchStart = batchEnd;
}
return s;
}
*Summary*
Upon manually updating the generated (prettified) GWT 2.8.0 compiler
output, I record that not only does the regression disappear, but the 2.8.0
shows a 30% speed boost over 2.7 (in Chrome). That's approx 13x faster than
prior to the change. Obviously this speed boost is very specific to my own
use-case (which is extremely string heavy)
I don't really know why the 2.7.0 implementation is so much faster than the
2.8.0 implementation. There are a lot of secret optimizations that occur in
JavaScript engines and mastering performance is nigh on impossible. All I
can say is that I tested and observed a 10x performance regression on
Chrome, 3x on Firefox, and 2x on IE with the new 2.8 code, although I
realise that a test harness would really help to prove the regression. I
wonder if someone can put one together?
Regards,
Chris
--
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/94423f7c-3c9e-4eae-a965-38885f035d05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
