[CSS/DOM] Performance IE7

[ajvdvegt]

Ik heb een tabel rijkelijk versierd met CSS (odd/even classes voor de rijen, en ook kolommen gegroepeerd door ze dezelfde kleur te geven). Ik heb voor FIrefox de CSS feature aan toegevoegd om een rij in het wit te laten oplichten door er met je muis boven te hangen:

code:

table {
  border-collapse: collapse;
}

table.highlight tr:hover td {
  background-color: #FFFFFF;
}

Dat het in IE6 en lager niet werkt, is jammer. Ik had gelezen dat dit wel in IE7 moet werken, en dat had ik verder niet getest (geen IE7 geinstalleerd hier). Nu blijkt het inderdaad wel te werken in IE7, maar het is TRAAG. in Firefox volgt de witte rij zonder enige vertraging je muiscursor, maar in IE7 duurt het wel 3 seconden! Je muis blijven bewegen boven de tabel zorgt voor 100% CPU load (op iets van een P4 3Ghz). Is daar wat aan te doen? Kan IE7 niet goed tegen kleurige tabellen?

En dezelfde tabel is ook sorteerbaar mbv. JavaScript door op de headers te klikken (het sorteren gaat via de DOM). Dat is in IE ca. 2x zo langzaam als in Firefox. Zijn er dingen waar ik op moet letten voor IE? Vroeger was IE volgens mij juist snel met bewerkingen op de DOM, is Firefox zoveel sneller geworden, of wordt IE steeds langzamer?

Oh ja, de tabel in kwestie kan vrij groot worden (ca. 500 rijen) en heeft ongeveer 10 kolommen. Is dat al te groot?

_{Ik zal kijken of ik ergens een voorbeeld kan posten...}

[crisp]

Hmmz, interesting. Dat de CSS-'improvements' in IE7 niets meer dan een hack-job is geweest is inmiddels wel redelijk bekend maar dat de :hover ondersteuning zo brak gedaan is wist ik nog niet - ik zal daar eens een testje op loslaten

Vwb DOM-bewerkingen: Firefox (en als je eens echt snelheid wil zien dan moet je Opera eens proberen) is wat dat betreft de laatste jaren inderdaad behoorlijk sneller geworden en heeft IE op veel punten al ver achter zich gelaten. IE wint het voornamelijk nog op rendersnelheid van Firefox (hoewel dat verschil in IE7 wel kleiner is geworden), maar qua script-exection en DOM-implementatie is IE nooit een snelheidsmonster geweest.

Maar als je een voorbeeldje online kan zetten kan ik wellicht nog wel wat tips geven om het ook in IE sneller te krijgen

[SchizoDuckie]

Hmmm my favorite subject... IE7 en de gevolgen van 5 jaar hacks op hacks stapelen

@Crisp: Misschien leuk om ook even te testen of het uitmaakt of je deze properties aanpast met javascript ipv css? (ik gok namelijk van wel, en dat maakt het (IE7) zo nodig nog triester )

[ Voor 16% gewijzigd door SchizoDuckie op 16-02-2007 01:08 ]

[mwargers]

Ze hebben tekst in IE7 'smooth' gemaakt (hoe heet dat ook alweer?). Ik heb het idee dat daardoor dingen nogal trager geworden zijn.

(om een of andere reden is IE7 zowieso erg traag op mijn computer, maar dat kan misschien een afwijking op mijn computer zijn)

[crisp]

Dat ClearType is het eerste dat ik uitgezet heb; de eerste keer dacht ik dat ik een bril nodig had of dat mijn monitor opnieuw afgesteld moest worden...

[sjaakaq]

ClearType werkt alleen goed op TFT monitoren en is dar (imho) onmisbaar...op CRT's "raak je er aan gewend", en is het na verloop van tijd (en hoofdpijn...) fijner voor lappen tekst, maar slechter voor losse zinnetjes en woorden (GUI elementen e.d.). Dat IE7 het default aanzet is dan ook "een schande", maar goed ik snap die hele browser niet, van de knopjes tot de semihacks die het "product" bij elkaar moeten houden...

[mwargers]

Oh ja, ClearType, en ja, ik vind het ook vreselijk en ik gebruik een TFT monitor.
Ik snap IE ook niet meer, ik vond IE5 geweldig, maar naar mijn mening is het daarna alleen maar berg afwaarts gegaan.

[ajvdvegt]

Ok, ik heb de pagina gestript van info en hier in een zipje neergezet.

En als er een JavaScript guru tijd overheeft : in het script sorttable.js staat nog een HEEL lelijke hack om in IE een onclick event toe te voegen:

code:

if (navigator.userAgent.indexOf("MSIE") > -1) {
    cell.innerHTML = cell.innerHTML;
}

[ Voor 27% gewijzigd door ajvdvegt op 18-02-2007 16:34 . Reden: bandbreedte verbruikt, dus alleen het zipje nog beschikbaar gesteld. ]

[Zerora]

In Opera 9.02 werkt dit wel goed. Wel met een klein beetje vertraging, een paar milliseconden, maar het is niet storend ofzo.

Ik ga zo ff IE7 checken hier voor je.
Hmm, dat traag is idd best vaag. Bij iedere mouse over zie je idd dat ie de CPU load ff omhoog gooit (in mijn geval van 0-10% naar 60-80%)

[ Voor 30% gewijzigd door Zerora op 16-02-2007 10:01 ]

[crisp]

ajvdvegt schreef op vrijdag 16 februari 2007 @ 09:22:
En als er een JavaScript guru tijd overheeft : in het script sorttable.js staat nog een HEEL lelijke hack om in IE een onclick event toe te voegen:

code:

if (navigator.userAgent.indexOf("MSIE") > -1) {
    cell.innerHTML = cell.innerHTML;
}

Tsja, je gebruikt i in een loop en krijgt zo een closure. setAttribute is verder niet bedoelt voor event-handlers. Ik zou zoiets doen:

JavaScript:

link.onclick = createSortFunction(i);

// ...

function createSortFunction(i)
{
  return function()
  {
    ts_resortTable(this, i);
    return false;
  }
}

addEvent kan je ook wel gebruiken, maar neem dan een versie die ook de tekortkoming van het IE-eventmodel oplost... (met name het scope-probleem)
In ieder geval zal je een wrapper moeten gebruiken om variabele i een eigen scope te geven.

[ Voor 18% gewijzigd door crisp op 16-02-2007 09:52 ]

[ajvdvegt]

@rakkerzero: tnx voor het testen in Opera, en leuk om te weten dat-ie het daarin ook goed doet.
@crisp: Ik zou idd het liefst addEvent() gebruiken. De scope van de variabele 'i' was inderdaad mijn probleem, ik zal eens kijken of die truc met extra functie werkt. Dank je!

[crisp]

Mwa, het gebruik van de DOM level 0 methode (element.onclick=) is hier best verdedigbaar. Ik zou echter geen anchor gebruiken - het is immers geen link.
Ik denk persoonlijk dat ik de handler op de header-cell zou zetten en mbv een css class de cursor zou aanpassen.

[Justice]

Ik dacht misschien als je de volgende code toe zou voegen het berekenen van het een en ander wat sneller zou gaan, maar helaas:

Cascading Stylesheet:

table { table-layout:fixed} /* heeft weinig invloed */

Wat ook vaag is, is dat de eerste keer de rij vrij snel oplicht, maar daarna is het langzamer

Maar goed ook het fixes zetten van body en dergelijke en line-height lijkt geen invloed te hebben, dus ik gok erop dat het parsen van html de bottleneck is, wellicht is er een debugger die je kan vertellen hoe lang IE7 over de paginaopbouw doet. Ik ken er geen.

[Suepahfly]

Als ik test in Opera en FF, is het meteen.
Ik heb zelf geen IE7,maar een maat verteld me dat het minder als een halve seconde duurt terwijl hij al op 90% cpu usage zit omdat er ander software gedraait word.

Ik zelf zat op 50% voor en tijden het testen in Opera en FF en kaar dus niets bespeuren (heb zelf geen IE7).