http://gwt-code-reviews.appspot.com/127801/diff/1101/1106 File reference/Microbenchmarks/src/com/google/gwt/reference/microbenchmark/client/Microbenchmarks.java (right):
http://gwt-code-reviews.appspot.com/127801/diff/1101/1106#newcode59 Line 59: horizontalPanel.remove(runningLabel); Here is a wild guess. Whatever structure IE uses for ID lookups (im assuming a hash table with chaining) depends on GC to run before cleaning up the IDs. Settimeout is a cue for IE to run GC. Things to try to test: 1. Give the things random ID's to see if the performance degredation is due to hash collisions on IDs. 2. Keep clicking the tests to see if somewhere along the line a GC happens and the numbers suddenly "get faster" after getting slower for a long time. On 2009/12/23 02:12:33, Ray Ryan wrote: > I've done this, and it has a drastic effect on the IE numbers. > When the tests run synchronously in the click handler, succeeding tests that > rely on getElementById roughly double in length on each click of the run button. > (!) By adding this deferred command, that pathology goes away. > I'm not sure what to do with this information. http://gwt-code-reviews.appspot.com/127801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
