Setting styles in loop creates a leak?

[B94Sport]

Well technically not a leak, since memory usage never goes up... But I've got a small piece of code that iterates through table rows #16-n (where n is the number of rows in a table) and changes their display style from "none" to "table-row." Seems simple enough, right? But after refreshing the screen a couple of times, it starts to load more and more slowly! I can't see what's causing it, or a way around it. Any insight? Here's the code:

var tbl = document.getElementById('tbl');
var trList = tbl.childNodes[1].childNodes;
var n = trList.length;
while (--n > 16) {
  trList[n].style.display = "table-row";
}

I've been able to isolate this as the problem with the page. If I comment out the line inside of the loop, the page does not slow down.

This happens in the latest IE6, tested on Windows 2000 and XP. It _does not happen_ in IE7.

 

[B94Sport]

I should also note that this slowdown is instance-specific. Meaning if you leave the page and come back, the trend continues. Even if you leave the domain. It does not get back to its initial loading speed until you close IE and reopen it.

 

[BillyRayPreachersSon]

I'm not sure I know the answer, but why would you need to set the display of a table row to "table-row" when it would already be displayed as a table row?

Try changing the second ".childNodes" to ".rows" - does this make a difference?

Incidentally, how many rows is your table likely to have? Are we talking 5 or 5000?

Dan



Coedit Limited - Delivering standards compliant, accessible web solutions

[tt]Dan's Page [blue]@[/blue] Code Couch

http://www.codecouch.com/dan/

[/tt]

 

[B94Sport]

Initially rows 16-n are set to display:none; This came as a big surprise to me, but setting them to display:none initially and then setting them to display:table-row through this function actually renders the page faster. At least in IE. If the widths of all columns could be known to me, I'd just to table-layout:fixed and call it a day. This is for an app where the clients like things to show up unrealistically fast, so I'm giving them the illusion of speed since the rest of the page cannot (as far as I can tell) be optimized past what it is now.

I'll try the .rows thing and post back.

The table is generally likely to have 30 rows or less, but sometimes it can have over up to 150. The number of rows does not affect the upward trend in load time though... Fewer rows = lower initial load time, but it doesn't eliminate the slow down.

 

[B94Sport]

.rows in .childNodes didn't change anything. It's still trending up 1/100th of a second per load. I know that doesn't really seem like an issue, but this screen is the main screen for the app and is hit constantly. Many clients just leave it displaying on one system, refreshing at least once/minute. Extrapolate this trend out over a week without a browser restart (which is common), and the page goes from loading in under 3 seconds to over a minute and a half!!

 

[monksnake]

My computer does the same thing (using IE6 Windows 2000). I will more than bet it's an IE6 bug.

<.

 

[B94Sport]

At this point that's what I'm thinking... But I can't find any documentation on it.

 

[BillyRayPreachersSon]

Are you using any JavaScript libraries such as Prototype? If so, does the page in question use any of the library calls?

Dan



Coedit Limited - Delivering standards compliant, accessible web solutions

[tt]Dan's Page [blue]@[/blue] Code Couch

http://www.codecouch.com/dan/

[/tt]

 

[B94Sport]

Nope, no libraries...

I created a stripped-down version of the page with limited stylesheet information but kept the same rows and row expansion code, and now it does not appear to be slowing down... But I will need to run the test for another hour or so to be sure. So the expansion function itself may not be the cause. This appears to be a multi-part problem involving stylesheets/style information and the JavaScript function. Removing either of the two solves the problem, but I need to figure out _why_. ARGH!

 

[BillyRayPreachersSon]

Have you tried giving the table a display style of "none", and showing the whole table in one go rather than a row at a time?

Dan



Coedit Limited - Delivering standards compliant, accessible web solutions

[tt]Dan's Page [blue]@[/blue] Code Couch

http://www.codecouch.com/dan/

[/tt]

 

[B94Sport]

I have not tried that yet, but it would defeat the purpose of what I'm trying to do, which is get limited content up on the screen quickly.

Yesterday I was able to (I think) isolate the problem to a specific column within the table. I just started collapsing columns, and after a certain group, the problem went away. Unfortunately there are 6 columns in that group, so now I have to figure out which one it was. I'll post back when I know more.

 

[BillyRayPreachersSon]

I wonder which is faster... Doing 10 full refreshes with your "display" code, or doing 10 full refreshes without it?

If the latter, it might be worth telling the client that their expectations are unrealistic.

Dan



Coedit Limited - Delivering standards compliant, accessible web solutions

[tt]Dan's Page [blue]@[/blue] Code Couch

http://www.codecouch.com/dan/

[/tt]

 

[B94Sport]

10 full refreshes with the display code is still faster than regular, even if it does start creeping.

I've narrowed it down to something that may make more sense.

In numerous cells within the table, I have spans with classes applied to them. These classes are in an external .css file that is sourced in through

<link rel="stylesheet" type="text/css" media="all" href="/style1.css" />

, and resemble the following:

background-image: url(/bad_icon.gif);
background-repeat: no-repeat;
background-position: right;
margin-left:2px;
height:16px;
width: 16px;

If I remove these cells, the problem goes away. I'm suspecting something strange is going on with the background image. Does this ring any bells? I still can't find any mention of something like this.

Many of these span instances can be removed simply by replacing them with the image itself, so that may be my solution. But they are used elsewhere in the application so that creates a maintenance issue. I have not tested to see if that eliminates the problem... If it doesn't, then I'm out of ideas again!

 

[BillyRayPreachersSon]

Out of interest, are your IE cache settings set to "Automatically" (which is the out-of-the-box setting more users will have), or "Check every time" (which most developers set their settings to, and will slow things down sometimes)?

Dan



Coedit Limited - Delivering standards compliant, accessible web solutions

[tt]Dan's Page [blue]@[/blue] Code Couch

http://www.codecouch.com/dan/

[/tt]

 

[B94Sport]

It's set to "automatically."

So I removed the empty spans with background images, and replaced them with regular img tags. This seems to have solved the problem! Not sure why the row showing code would have affected this, but clearly the two cannot play nice together.

I've got one more test running tonight that will refresh the screen 2,400 times, and then I should know for sure. But I've already tested it twice with 500 refreshes and the rendering time trend line is flat.

 

[BillyRayPreachersSon]

I've a hunch about one potential way to get around this without removing the BG image, although it would depend on your rows having a fixed, known height (so might not work if you have chosen a scalable font).

The idea would be to have 1 image as a BG to the table, positioned top right, and repeating downwards. The image would have enough whitespace above and below it so that it appeared centred in each row.

Dan

Coedit Limited - Delivering standards compliant, accessible web solutions

[tt]Dan's Page [blue]@[/blue] Code Couch

http://www.codecouch.com/dan/

[/tt]

 

[B94Sport]

Unfortunately the background images are not repeated in each cell, and I have multiple instances of different images positioned throughout each row...

For now removing the empty spans and replacing them with img tags has fixed the problem. I've refreshed the screen over 3,000 times and each load now increases an average of .00008 seconds instead of .001 seconds. That small increase is perfectly acceptable.