Challenge.. what is the RPC bottleneck in IE6

[rd]

FF is 21 times faster in 1.1 than 1.0.21 (very good)
IE6 is only 2 times faster (not so good)

This test was done by modifying the DynaTable example. look up this
thread for more details "RPC still slow in IE 6"

use "gen -gen" to see the generated classes...

(loading 2000 Person objects in DynaTable)
1.0.21
47362ms hosted IE6/Win32
28330ms web IE6/Win32
20298ms web FF/Win32

1.1.0
24470ms hosted IE6
8391ms web IE6/Win32
953ms web FF/Win32

[Dave]

Would it be possible to run the test with the GUI updates turned off
(not actually putting rows into the table) so we could differentiate
between the amount of time that is being spent on the actual RPC call
vs the time spent in updating the HTML DOM.

Dave

[rd]

dave, in my testing i never do actually populate the table. i just
print stop and start times to the screen. so there is no (well there
shouldn't be anyway) gui dependency on the # of objects. we could
strip it down more but i'm pretty sure the problems is some where in
the generated client de/serialization code ("gen -gen" to see).

rob

[Dave]

OK. When I saw Dynatable I thought the visual representation of the
data was being changed as well.

Dave

[Scott Blum]

rd, you forgot to mention:

a) I'll mention you in the GWT blog if you can find a way to make IE
significantly faster.

b) Those are my numbers. ;)

Scott

[ash]

> b) Those are my numbers. ;)

scott here are my numbers but i cant explain them. for me IE performs
_signficantly_ better than ff.

first of all here is some generated code that i have wrapped with
profiling. i have provided u guys as as much as i can b/c my results
are opposite to yours. i _must_ be doing something wrong.
1. http://ashinw.googlepages.com/slowrpccode

here are my FF results
2. http://ashinw.googlepages.com/slowrpcff1.5.0.6

here are my IE6 results
3. http://ashinw.googlepages.com/slowrpcie6

you will notice that i had to drop the payload down to 40 people
objects. ff kept interupting with "continue script" messages. i wanted
to eliminate that.

the numbers at the end in parenthesis represent elapsed time since the
beginning of its associated instruction set.

based on this analysis, i would be asking why is the spotlight on ie?
pls let me know what ive done wrong.

rgds ash

[georgeuoa]

An excellent guide on (non obvious) cross browser optimisation
techniques:

http://home.earthlink.net/~kendrasg/info/js_opt/

[cole...@gmail.com]

I can't beleive no ones done this optimization. It's pretty easy and
IE is now nearly the same speed as Firefox was. I'm not sure if there
is a signifcant change in Firefox's speed.

In ClientSerializationStreamReader, set index to results.length (using
a native method to get the array length.) Then, instead of
results.pop(), always do
results[--this.@com.google.gwt.user.client.rpc.impl.ClientSerializationStreamReader::index];

In my tests I serialzed 3000 DataObjects which each contained two
Strings and one unique Date.

(median of 3 test run in a succession on a 1.80 ghz pentium M)

Before:
Firefox: 854ms
IE: 14306ms

After
Firefox: 723ms
IE: 923ms

It cuts the time by about a fifteenth. Thats a 1550% speed improvement!

[Sam Gross]

Here's the modified ClientSerializationStreamReader. Just put it in
com.google.gwt.user.client.rpc.impl in your project's source folder.

-Sam

[rd]

Thanks guys, that did the trick (1 second loads) but........ running in
hosted mode it still me about 20 - 30 seconds to load 2000 objects.
any ideas on how to fix that one?

[Scott Blum]

Sam, let me verify your suggested change, but if this works you'll get
a blog mention!

Scott

[Scott Blum]

I've tested this out, and indeed it speeds up IE to be comparable to
FF performance! I've also run our unit tests on IE and it appears to
not break anything. So pending any problems showing up in our
cross-browser testing, we'll get this optimization into the upcoming
release.

Great work Sam, thanks a lot!

How would you prefer to be recognized in the blog post? We can
include your email address, or a link to your website or blog.

Scott