By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,422 Members | 1,338 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,422 IT Pros & Developers. It's quick & easy.

Perf prob with IE

P: n/a
Raj
Hello all:

We have a table with about 2400 cells. Our requirement is to highlight
the cells in the table whose data has changed, every 5 seconds. Our
script behaves relatively ok in Firefox, but the performance in IE
really bad. Have attached a simple html which simulates the prob. Any
inputs on how to improve the perf in IE are greatly appreciated.

Thanks,
Raj
---
<HTML>
<HEAD>
<style>
.normal_td { background-color: #DDDDDD }
.red_td { background-color: #FF0000 }
.blue_td { background-color: #0000FF }
</style>
<script language="JavaScript1.2">
var kk=100;

function updateTableCells()
{
var tbl = document.getElementById("tbl");
var tds = tbl.getElementsByTagName("td");

for(var k=0; k<tds.length;k++)
{
tds[k].firstChild.nodeValue = kk;
var rem = kk-(parseInt(kk/7)*7);

if(rem == 0)
setClassName(tds[k], "red_td");
else if(rem==5)
setClassName(tds[k], "normal_td");
else if(rem==2)
setClassName(tds[k], "blue_td");
else
setClassName(tds[k], null);
kk++;
if(kk>10000)kk=5000;
}
}

function setClassName(n, name){
if(n.className!=name)
n.className=name;
}

function init(){
var str="<table id='tbl'>";
for (var i=0;i<150;i++)
{
str+="<tr>\n";
for (var j=0;j<16;j++)
{
str+="<td id='ele"+i+"_"+j+"'>"+j+"</td>\n";
}
str+="</tr>\n";
}
str +="</table>";
var bod = document.getElementById("bod");
bod.innerHTML=str;
setInterval('updateTableCells()','5000');
}

window.onload = init;
</script>
</HEAD>
<BODY id="bod"/>
</HTML>
Jul 23 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
Raj wrote on 06 dec 2004 in comp.lang.javascript:
We have a table with about 2400 cells. Our requirement is to highlight
the cells in the table whose data has changed, every 5 seconds. Our
script behaves relatively ok in Firefox, but the performance in IE
really bad. Have attached a simple html which simulates the prob. Any
inputs on how to improve the perf in IE are greatly appreciated.


<td>s do not change by themselves,
but if you mean by "changed" <input>s changed by the user,
try for IE:

input { background-color:expression(value!=defaultValue?"cyan":"");}

I don't know the performance loss of the expression() syntax with such an
silly large number of <input>s
Jul 23 '05 #2

P: n/a
Hi Evertjan:

Every 5 secs fresh data is downloaded from the server. The downloaded
data is compared against the data currently being displayed in the
table. If any of the cells have changed, the javascript updates the
value of the cell and changes the cell color based on whether the
change is positive or negative from the previous value.

Jul 23 '05 #3

P: n/a


Only 2400? :0

http://www.peachpit.com/articles/article.asp?p=31567

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Jul 23 '05 #4

P: n/a


Just a thought: why not have the server determine this, and return a
(DOM-oriented) JS which does the highlighting?

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Jul 23 '05 #5

P: n/a
VK
IE doesn't use DOM for tables, it uses its proprietary TOM.
The DOM's childhead in this case is just a mimic interface atop of TOM (to
keep 3W happy).

(1) So the first major "perf" improvement you are getting by working
directly with TOM:

if (navigator.appName.indexOf('Microsoft')! =-1) {
/* a sample iteration thru all cells,
presuming you have only one <tbody> tag: */
var oBody = document.getElementById(tableID).tbodies[0];
for (i=0;oBody.rows.length;i++) {
for (j=0;oBody.rows[i].cells.length;i++) {
if (oBody.rows[i].cells[j] == myCriteria) {
/* Or: oBody.rows[i].cells[j].innerHTML == myCriteria */
/* (2) The runtime style class reassignments seems very academically
profound,
but it's VERY resource consuming.
You are saving A LOT by using runtimeStyle object,
and by changing only properties you need to change */
oBody.rows[i].cells[j].runtimeStyle.backgroundColor = highlightColor;
}
}
}
}

(3) If you are getting data updates from the server, then the server knows
what cells have been changed. So instead of making your script behave like a
tiger in the cage, looping every time thru all cells, you could receive
{i,j} indexes of updated cells directly from your server.

(4) Actually all this structure is "screaming" for data binding, this would
give you the "max perf".


Jul 23 '05 #6

P: n/a
Hello Rob,

Doing the checks on the server side would be scalability issue. It
would be better if we could utilize the client CPUs for rendering.

Jul 23 '05 #7

P: n/a
wrote on 06 dec 2004 in comp.lang.javascript:
Every 5 secs fresh data is downloaded from the server. The downloaded
data is compared against the data currently being displayed in the
table. If any of the cells have changed, the javascript updates the
value of the cell and changes the cell color based on whether the
change is positive or negative from the previous value.


This is not email. Your answer is read by many, so PLEASE quote a relevant
part of the original. Follow usenet netiquette.

==================

Downloaded to a HTML table, how, why?

Then you loose the original table cell content, I suppose.

I suggest you do such comparing on the server, not on the client browser.

Evertjan.

Jul 23 '05 #8

P: n/a
VK wrote:
IE doesn't use DOM for tables, it uses its proprietary TOM.
The DOM's childhead in this case is just a mimic interface atop of TOM (to
keep 3W happy).

(1) So the first major "perf" improvement you are getting by working
directly with TOM:

if (navigator.appName.indexOf('Microsoft')! =-1) {


<--snip-->

And you have just introduced a very unreliable method into your script.
Namely, by trying to identify the browser based on the navigator object.
A better solution is to test for the actual object/properties you want
to use. The c.l.j FAQ covers it.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq
Jul 23 '05 #9

P: n/a
>> Every 5 secs fresh data is downloaded from the server. The
downloaded
data is compared against the data currently being displayed in the
table. If any of the cells have changed, the javascript updates the
value of the cell and changes the cell color based on whether the
change is positive or negative from the previous value.

This is not email. Your answer is read by many, so PLEASE quote a relevantpart of the original. Follow usenet netiquette.
I am using http://groups.google.com which has pretty much gmail like
threaded view, so didnt realize the problems other face. Will
copy+paste the relevant parts ... sorry and thanks.
Downloaded to a HTML table, how, why?
Then you loose the original table cell content, I suppose.
I suggest you do such comparing on the server, not on the client

browser.

Ok ... let me try to elaborate on the problem. The application shows
the prices of stocks being traded in a web page. When a user logs in to
the application, they can select the stocks they are interested in.
They are then taken to a page which shows the price [and other details]
of the stocks in the form of a table. Every 5 secs there is a script
which downloads the new price list [in csv format] and updates the
cells which have changed. The background colour of the cell is changed
based on whether the new value of the cell is more/less than the
current value.

We did consider forming the HTML [with new background colours] on the
server side. This increases the CPU load on the server side. The
current model uses client side CPU to do the rendering and it works
fine in case of the rich client and incase of firefox browser. The
problem is only with IE. Once the page is loaded in IE, it takes 100%
CPU for couple of mins and then drops for a sec or so and then it takes
off again.

I donot think it is a problem with changing the style of the cells.
Just updating the cell values takes up a whole lot of CPU:

function updateTableCells()
{
var tbl = document.getElementById("tbl");
var tds = tbl.getElementsByTagName("td");
for(var k=0; k<tds.length;k++)
{
tds[k].firstChild.nodeValue = kk;
kk++;
if(kk>10000)kk=5000;
}
}

Jul 23 '05 #10

P: n/a
Raj
>> Every 5 secs fresh data is downloaded from the server. The
downloaded
data is compared against the data currently being displayed in the
table. If any of the cells have changed, the javascript updates the
value of the cell and changes the cell color based on whether the
change is positive or negative from the previous value.

This is not email. Your answer is read by many, so PLEASE quote a relevantpart of the original. Follow usenet netiquette.
I am using http://groups.google.com which has pretty much gmail like
threaded view, so didnt realize the problems other face. Will
copy+paste the relevant parts ... sorry and thanks.
Downloaded to a HTML table, how, why?
Then you loose the original table cell content, I suppose.
I suggest you do such comparing on the server, not on the client

browser.

Ok ... let me try to elaborate on the problem. The application shows
the prices of stocks being traded in a web page. When a user logs in to
the application, they can select the stocks they are interested in.
They are then taken to a page which shows the price [and other details]
of the stocks in the form of a table. Every 5 secs there is a script
which downloads the new price list [in csv format] and updates the
cells which have changed. The background colour of the cell is changed
based on whether the new value of the cell is more/less than the
current value.

We did consider forming the HTML [with new background colours] on the
server side. This increases the CPU load on the server side. The
current model uses client side CPU to do the rendering and it works
fine in case of the rich client and incase of firefox browser. The
problem is only with IE. Once the page is loaded in IE, it takes 100%
CPU for couple of mins and then drops for a sec or so and then it takes
off again.

I donot think it is a problem with changing the style of the cells.
Just updating the cell values takes up a whole lot of CPU:

function updateTableCells()
{
var tbl = document.getElementById("tbl");
var tds = tbl.getElementsByTagName("td");
for(var k=0; k<tds.length;k++)
{
tds[k].firstChild.nodeValue = kk;
kk++;
if(kk>10000)kk=5000;
}
}

Jul 23 '05 #11

P: n/a
VK
> if (navigator.appName.indexOf('Microsoft')! =-1) {

<--snip-->

And you have just introduced a very unreliable method into your script.
Namely, by trying to identify the browser based on the navigator object.
A better solution is to test for the actual object/properties you want
to use. The c.l.j FAQ covers it.


Exceptions are just proof of the rule :-)

In this particular case:
1) There is only one browser using TOM, and it will be only one (unless
Mozilla & Co deside to drop standards and follow Microsoft :-).
2) Methods/properties check gets more and more difficult in IE, because they
are actively covering their non-standard parts with mimic DOM-interfaces,
like one mentioned in my OP.

So in this particular case a simple name check MAY be the most reliable way.


Jul 23 '05 #12

P: n/a
On Tue, 7 Dec 2004 14:48:12 +0100, VK <sc**********@yahoo.com> wrote:

[snip]
1) There is only one browser using TOM, and it will be only one (unless
Mozilla & Co deside to drop standards and follow Microsoft :-).
If you're dealing solely with IE, then use conditional comments. However,
I can't recall having any problems using the W3C DOM to manipulate table
structures in IE.

[snip]
So in this particular case a simple name check MAY be the most reliable
way.


No, it won't. The very reason for not sniffing is that browsers do fake
their identity, but more often than not, they do not actually emulate that
browser functionally. Your test would pick up Opera if it were spoofing
IE, but Opera only has limited support for the proprietary nonsense that
IE includes.

If you'd rather use Microsoft's proprietary object model, then test for
that before methods and properties of the W3C DOM.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Jul 23 '05 #13

P: n/a
VK
> I can't recall having any problems using the W3C DOM to manipulate table
structures in IE.


Mmm... Clone rows within the table or to another table? Get/alter rows'
content? Speedy cells manipulation in a Big x Big table (see the OP)?
So in this particular case a simple name check MAY be the most reliable
way.


No, it won't.


<snip>

Conceived and agreed
:-) :-|
Jul 23 '05 #14

P: n/a
On Tue, 7 Dec 2004 15:58:13 +0100, VK <sc**********@yahoo.com> wrote:
I can't recall having any problems using the W3C DOM to manipulate
table structures in IE.
Mmm... Clone rows within the table or to another table?


Yes. IE has no problem with HTMLTableRowElement.cloneNode nor
HTMLTableSectionElement.appendChild.
Get/alter rows' content?
Yes, but I'll admit that can get awkward. It depends on the content and
what you're doing with it.
Speedy cells manipulation in a Big x Big table (see the OP)?


Personally, I wouldn't attempt to do that at all in a browser. It's not
suited to the job.

[snip]

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Jul 23 '05 #15

P: n/a
"VK" <sc**********@yahoo.com> wrote:
Speedy cells manipulation in a Big x Big table (see the OP)?


http://www.quirksmode.org/dom/innerhtml.html suggests the OP should
give recreating the table in a string and then assiging using innerHTML
a try.

Bye,
Martin
Jul 23 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.