IE 6 is our corporate standard and everyone is required to use IE. We have discovered in one of our recent applications that performance is significantly degraded while manipulating/validating grid data on client side (using javascript). For instance, it takes more than 20 seconds to select a checkbox by looping through 120 rows of data. I am wondering is this is an IE DOM defeciency or is it something that can be improved in the grid (or perhaps in the script).
We have tested the this page in FireFox and the same code goes through the whole grid in less than 2 seconds (data modification) and less than one second for validation. Even though this response is slow but is acceptable to the users.
Could you please suggest a solution for the above?
Thanks
There are some key areas in IE where scripting/DOM manipulation is less then stellar. Here are a couple of things to watch out for.
String manipulation is very slow. Appending 1000 characters together is orders of magnitude slower than inserting 1000 characters into an array and performing a join on the array. Because of this, many script libraries (including Microsoft's AJAX Extensions) have a StringBuilder class that can be used.
Accessing objects in the DOM can be slow, and objects references aren't cached. This means if you have a line like foo.bar.childElements[0].firstChild, the entire chain must be processed each time. Add 4 of these lines in a row and you end up with very slow code. Avoid this scenario by caching references yourself.
As an example turn a.b.c.childElements[0].firstChild.style.backgroundColor=red;a.b.c.childElements[0].firstChild.style.fontFamily="verdana"; INTO var style=a.b.c.childElements[0].firstChild.style;style.backgroundColor=red;style.fontFamily="verdana";
As an example turn
a.b.c.childElements[0].firstChild.style.backgroundColor=red;a.b.c.childElements[0].firstChild.style.fontFamily="verdana";
INTO
var style=a.b.c.childElements[0].firstChild.style;style.backgroundColor=red;style.fontFamily="verdana";
Also, IE's InnerHTML method can be extremely slow. Because of this avoid scenarios where you're constantly appending to the InnerHTML string.
As an example, turn element.innerHTML+="<div>hello</div>";element.innerHTML+="<div>world</div>"; INTO var content="<div>hello</div>";content+="<div>world</div>";element.innerHTML=content;
As an example, turn
element.innerHTML+="<div>hello</div>";element.innerHTML+="<div>world</div>";
var content="<div>hello</div>";content+="<div>world</div>";element.innerHTML=content;
To make that even more efficient, use the string builder to build your content rather than string concats.
Also, be aware that the WebGrid uses a lazy create pattern on the client-side for all objects. A grid oRow object isn't created until it is requested. This may be the result of a user performing selection, or your code calling "getRow(i)". It sounds like you'll need to loop through each row so you can't avoid it, but it's good to be aware of it either way. I've also seen some minimal results changing a for loop from increasing to decreasing or making it a while loop. These optimizations really get down to the dirty details of the browsers's javascript implementation which means you're looking at a minimal gain - but still something that you may want to look at.
If you can't get the script running faster, post your code for the checkbox selection here and I'll give it a while on my end. We may even find some room for optimization on the grid side of things.
Funny, we've been avoiding using any version of UltraWebGrid v7.3+ because all of a sudden sorting in our UltraWebGrid takes magnitudes longer than before. Even stranger, this timing occurs even though we are performing the sort server-side using our own code. The server-side code runs as quickly as before, but for some reason rendering the UltraWebGrid after performing a sort (v7.4+) can take 30+ seconds, whereas in v7.3 it takes only a second or two.
I never thought this might be an IE issue. After seeing this post, I tried our application on FireFox and sure enough, even when using a more recent version of UltraWebGrid (such as v8.1), response time is a quick 1-2 seconds. On IE, it can be 30+ seconds.
In my situation, there is nothing I can do because Infragistics must have added some client-side code that processes after sorting (even if sort was handled server-side). Any suggestions to get around this problem? Our company standard is IE so I can't force everyone to use FireFox.
Thanks!
Hi metzgda ,
I saw your posting regarding performance in firefox compared to IE. I am having the same issues and also have a standard of IE at my company. Have you found any workaround for this? Were you able to increase the sorting/loading performance of the grid in IE?
Veni -
I've been receiving quite a few bug fix notices from Infragistics and decided along with your e-mail to try the latest HotFix versions of the ASP.NET Infragistics controls. It appears that the performance issues have been resolved at least for us. Our code as of now is still performing the sort in a custom way on the server-side, but there is no notable delay when the screen is refreshing like it was previously. My recommendation is to download the latest hotfix and see if it resolves your issue.
That being said, as it seems whenever I win one battle I lose another. The latest hotfix versions seem to completely ignore the fact that I have CSS styles applied to our WebGrid. I tried installing the latest hotfix I received in e-mail for v8.2 (8.2.20082.1002) and v8.1 (8.1.20081.2038) and nothing but our GridStyle seems to be applied (all Row and header styles are being ignored in all bands). If I instead install v8.1.20081.2013 for example, the styles reappear but the sorting is not fixed.
If you don't use cascading stylesheets, I'd say the latest HotFix might fix your problems. Otherwise, beware.
BTW Infragistics, what the heck happened to the CSS on the UltraWebGrid? I've wasted hours trying to figure out why they are suddenly not being rendered (even checked the HTML) in the latest hotfixes.
Ok, thanks for the update. I'm going to add this to a "known issues" section of the forums for others to read as well.
-Tony
Hi Tony,
Thanks for looking into this. Unfortunately the styling is broken in version 8.1.2046 and was verified. It turns out that setting the default styles for the entire grid works fine, but if you set the styles at the band level (which is what we're doing since we have multiple levels) then it's ignored.
This is being tracked under Issue ID BR35073. Once this gets fixed, I'll be able to get back to work here...
Hi Guys,
I had someone in our QA department take a look at this, and they verfied that the latest hotfix does indeed fix the grid row/header styling issue.
Here were the results -
- 8.2.1002
- 8.1.2013 (the version that customer claimed to work fine). Although the header style is appeared okay.
Hope this helps. If you need more details on this bug or any others, remember you can always contact our support department directly through http://www.infragsitics.com/gethelp