Details
-
Type: Improvement
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 1.8.2
-
Fix Version/s: 1.8.2-EE-GA, 1.8.3
-
Component/s: Bridge
-
Labels:None
-
Environment:IE6
Description
Ted's findings:
"There are probably three main phases where we could
exhibit poor performance in IE: serializing the form,
updating the browser DOM, and cleaning up listeners.
By observing the timing of network operations for
Joanne'sICE-2619 test case (nothing is sent to the server
until a significant amount of time after a user event),
it looked worthwhile to measure our serialization
performance. Here's the simple test case with a large
table:
http://server.ice:8888/svn/repo/qa/trunk/Regression/ICE-2619
Theoretically, we need something like the following
script to serialize the form, so it was added it to the
page just as an in-line script. It takes 1500 - 2000
milliseconds to serialize the same large form:
var buf = [];
formElements = form.getElementsByTagName("input");
var N = formElements.length;
for(i=0; i < N; i++){
line = formElements[i].name + "=" + escape(formElements[i].value );
buf.push(line);
}
cat = buf.join("&");
(I had several false starts here -- using += for string
concatenation led to 10x - 20x slowdown.)
In contrast, ICEfaces takes 48000 milliseconds to serialize
the form.
In connection.js, we have the following two lines (actually
one line is pulled out of a function parameter so time
could be measured for it):
this.logger.debug('send > ' + compoundQuery.asString());
var uriEncoded = compoundQuery.asURIEncodedString();
Each of these lines appears to take about 20s. To verify
that my timing measurement was not interfering, the
logging line was commented out, leading to 63s vs 31s
without the logger call. "Fortunately", IE is slow enough
that it can be profiled in this test case with a stop watch.
(I don't believe it's the logging itself causing the
problem -- compoundQuery.asString() passed to the logger
is implemented in an expensive way somehow using the
prototype.js collection operations.)
So, one strategy would be to replace some of the
prototype.js collection operations with hand-optimized
code. At the very least, the logging should be disabled
when logging output is not visible (if this is not possible
to detect, logging should be disabled by default). "
"There are probably three main phases where we could
exhibit poor performance in IE: serializing the form,
updating the browser DOM, and cleaning up listeners.
By observing the timing of network operations for
Joanne's
until a significant amount of time after a user event),
it looked worthwhile to measure our serialization
performance. Here's the simple test case with a large
table:
http://server.ice:8888/svn/repo/qa/trunk/Regression/ICE-2619
Theoretically, we need something like the following
script to serialize the form, so it was added it to the
page just as an in-line script. It takes 1500 - 2000
milliseconds to serialize the same large form:
var buf = [];
formElements = form.getElementsByTagName("input");
var N = formElements.length;
for(i=0; i < N; i++){
line = formElements[i].name + "=" + escape(formElements[i].value );
buf.push(line);
}
cat = buf.join("&");
(I had several false starts here -- using += for string
concatenation led to 10x - 20x slowdown.)
In contrast, ICEfaces takes 48000 milliseconds to serialize
the form.
In connection.js, we have the following two lines (actually
one line is pulled out of a function parameter so time
could be measured for it):
this.logger.debug('send > ' + compoundQuery.asString());
var uriEncoded = compoundQuery.asURIEncodedString();
Each of these lines appears to take about 20s. To verify
that my timing measurement was not interfering, the
logging line was commented out, leading to 63s vs 31s
without the logger call. "Fortunately", IE is slow enough
that it can be profiled in this test case with a stop watch.
(I don't believe it's the logging itself causing the
problem -- compoundQuery.asString() passed to the logger
is implemented in an expensive way somehow using the
prototype.js collection operations.)
So, one strategy would be to replace some of the
prototype.js collection operations with hand-optimized
code. At the very least, the logging should be disabled
when logging output is not visible (if this is not possible
to detect, logging should be disabled by default). "
Replace 'inject' operation with a straight forward loop. Use 'join' for concatenating all the serialized parameters. Limit output of Query.asString() method to only 25 lines.