IE performance

[ABM]

We are using SC6.5, client-side only (no server components), talking to a .NET backend via webservices. We have some significant performance differences between Firefox and IE and would appreciate some advice on best-practices on performance-monitoring in IE.

Using Firebug, we are able to very clearly measure the performance of our application. A typical interchange is as follows:

a) Client-side JS makes webservice call to server to retrieve screen layout
b) Client-side JS parses received responses (in XML), creates SC forms/ components on-the-fly
c) Client side application JS makes webservice call to server to retrieve data to be displayed
d) Returned data bound to components, form rendered and data displayed.

In our tests, under Firefox 3.5, this entire process takes approx 5-7 seconds, whilst *exactly* the same application, running under IE6 takes approx 20 seconds. These are tested under controlled conditions, from the same machine, one after the other.

In firebug, in the network tab, we are able to see the time taken for each web service call, and using these measurements, along with some developer-consol output, plus manual tracing, have been able to determine that the main difference between the FF and IE timings appears to be down to JS object creation and manipulation on the client-side.

The reason for the posting is to ask:

a) When looking to do firebug-type tracing in IE, what tools are people using - event the 'firebug lite' for IE does not seem to come close to what Firebug gives? From our testing, our webservice calls appear to be more or less the same out of FF and IE.

b) JS object creation/manipulation browser-side. Unfortunately, the developer consol seems to interfere too much with the actual JS execution, and figures are distorted. What we can see however is that the same JS seems to be anything up to twice or three times as slow on IE as compared to FF. Unfortunately we cannot ask all clients to use FF - especially in public sites...

Our forms are complex, and we are looking at simplifying them, but at the end of the day the dataset to be displayed is complex.

If anybody has undertaken detailed performance tracing/analysis under IE I would be very grateful for any suggestions as to client-side setup/toolset usage suggestions etc.

Many thanks

[Isomorphic]

Log.timeMethod() can produce some coarse-grained benchmarks so long as you keep the Developer Console closed during the actual test run and only open it aafter the run is complete.

IE8 has profiling tools, but you're really only going to see this large of a gap in IE6 - even an upgrade to IE7 would close the gap significantly.

Finally, it's not really surprising to see a gap this large between FF and IE6 in a WSDL integration scenario, however, it is surprising that *any* application could be made to run that slow in FF 3.5. We would suggest looking for "big picture" optimizations that affect both browsers because with those numbers it seems likely tahr unnecessary work is being performed somewhere.

[ttubbs]

We also see a noticeable performance differences between FF and IE. We are running FF 3.x and IE 6, 7 & 8. We are still in a proving mode, figuring out if we can do all the things we'd like to with SC. But, we are interested in the performance issues as well. We have clients running IE 6, and that's just something we have to live with. We've done a little bit of IE 6 testing, mostly to see if things visually are as desired (they are), and seem to get the same performance in IE 6 as we do with IE7 and 8. (Oddly, IE 8 has more visual issues than we are seeing with IE 6 right now.)

Don't have anything to add that will help. Just interested in tips & tricks to watch out for as well.

[Isomorphic]

IE8 is very noticeably faster than IE7, which is very noticeably faster than IE6. If you aren't seeing this, something is probably wrong with your testing methodology.

The primary performance issue with IE6 is a flawed garbage collector that causes the performance of larger applications to degrade as more components are created and more data loaded. There are many articles on the web about the flaw and it's effects. SmartClient contains some pretty spectacular workarounds to minimize performance degradation in IE6 - for example there are huge swaths of critical path code where we avoid creating even a single String, Object or Array, so that the garbage collector has no impact.

In application code, you can minimize the effects by carefully managing the component lifecycle, eg, using clear() and invalidateCache() on screens which are not visible and aren't likely to be used again for a while.

Note that any side by side performance test of two frameworks in IE6 *must* be done as a stress test involving the typical component and data load expected in the final application. Otherwise the results are completely meaningless. It's also meaningless to perform a side by side test where the SmartClient version supports all of the features of the final application and the competing framework doesn't (yes, we really see people do this, all the time in fact).

On IE8 glitches - there are a couple of known glitches specifically in IE8 strict doctype when IE7 compatibility mode is not used. Already corrected in our mainline codebase, but there's little we can do about released versions when a vendor just breaks backcompat.