[browsers] Internet Explorer vs. Mozilla: IE traag???

[Explore]

Aangezien het tegenwoordig vrij simpel is om een site cross-browser te maken orienteer ik me extra op Mozilla. Waar ik de laatste tijd nogal eens tegenaan loop is het feit dat Internet Explorer het steeds vaker moet afleggen tegen Mozilla.

Zo heb ik bijvoorbeeld een array van ruim 600 vrij grote objecten. In een loop wordt hier doorheen gelopen om van een aantal properties van de objecten een HTML-tabel te maken. Deze tabel wordt uiteindelijk in een layer gegooid en zodoende zichtbaar gemaakt.

Vrij standaard, zou je zeggen. IE hangt echter enkele seconden het systeem op om de tabel te maken, terwijl Mozilla er totaal geen moeite mee heeft.

De Javascript code om de tabel te maken ziet er ongeveer zo uit:

JavaScript:

// Loop through objects
var o;
var nItems = this.objectlist.length;
var s = '<table cellpadding="1" cellspacing="0" border="0">';
for (var i = 0; i < nItems; i++) {
    o = this.objectlist[i];
    s += '<tr id="row'+o.id+'" onmouseover="rowOver('row'+o.id+'')"
        onmouseout="rowOut('row'+o.id+'')">';
    s += '<td class="item" width="30" align="right">'+o.id+'</td>';
    s += '<td class="item" width="30" align="center">'+o.somefield+'</td>';
    s += '<td class="item" width="300">'+o.anotherfield+'</td>';
    s += '<td class="item" width="40" align="center">'+o.yetanother+'</td>';
    s += '</tr>';
}
s += '</table>';

Ik had eerst nog een for...in loop, maar dacht dat IE dat wellicht te ingewikkeld vond worden. Dat maakt dus niet uit.

Hoe komt het dat IE hier zo'n moeite mee heeft? Is er een manier om dit process te versnellen?

Edit: om duidelijk te maken dat ik geen onzin uitsla, heb ik bovenstaande loop getimed. Mozilla heeft strak en consequent 94 milliseconden nodig om dit klusje te klaren. Internet Explorer doet 't in maarliefst 40 seconden! Wat is hier aan de hand?

[ Voor 23% gewijzigd door Explore op 28-10-2003 15:58 ]

[sirdupre]

Stuur een mailtje naar Microsoft. Die vinden het meestal niet leuk als open source software iets sneller kan dan hun software. Toen bleek dat samba sneller was dan hun eigen smb-implemenatie hebben ze daar ook hard aan gewerkt.

[Explore]

Ik denk dat de grond toch al heet wordt onder hun voeten. Er komen steeds meer Open Source oplossingen die een (beter!) alternatief bieden voor Microsoft's dure software.

Dit lost echter m'n probleempje nog niet op, want ik wil eigenlijk wel dat m'n tabelletje in een fatsoenlijke tijd wordt gegenereerd - ook in Microsoft software...

[crisp]

Kan je een complete testcase online zetten?
Mijn ervaring is wel dat Mozilla 50 tot 100% sneller is dan IE wb JS executie, maar dit verschil is wel heel erg groot...

[Explore]

crisp schreef op 28 October 2003 @ 16:37:
Kan je een complete testcase online zetten?

Ik zou wel willen maar het gaat om een op maat gemaakt CMS voor een klant met gegevens uit een database die ik liever niet op deze manier publiekelijk maak.

Ik zal eens kijken of ik een simpele test-case in elkaar kan zetten.

To be continued...

Edit:

Oke, ik heb een sterk versimpelde versie online gezet: http://www.davdigital.com/testcase/

Ondanks het feit dat hier het object wat in een array wordt gezet uit niet meer bestaat dan een random string, is het effect van de tabel creeren al wel duidelijk: IE is weer trager. Blijkbaar loopt dat effect op als het object ingewikkelder wordt (zoals in de code waar ik mee bezig ben).

Bij mij maakt Mozilla een tabel met 1000 items in 47 milliseconden en IE in ruim 300 milliseconden. Scheelt ook wel een hoop.

Kijk in de source om te zien wat er achter de schermen gebeurd. Er wordt geen server-side code gebruikt in dit voorbeeld.

[ Voor 45% gewijzigd door Explore op 28-10-2003 17:17 ]

[BetuweKees]

hier 50ms voor firebird 0.7+ (20031026)
1810ms voor opera 7.11
en ie5 wil niet..


maar volgens is verschil ook vrij afhankelijk van soort functie die je uitvoerd in js.. tijdje terug nog een progje geschreven dat vnl dingen met document.write doet; nu nog eens gebenchmarked, ie5 en opera doen dit scriptje in ong 500ms, terwijl firebird daar weer stukken langer over doet (ong 1500ms)

[Robthebest]

Heb hier WINXP met IE 6.0.2800.1106.xpsp2.030422-1633 en hij doet her maar 235 milliseconds over

[Verwijderd]

WIN XP SP1 IE doet er 78 miliseconds over, Firebird doet er slechts 17 miliseconden over

[crisp]

mooie testcase; je ziet ook al duidelijk dat het tijdverschil al heel duidelijk naar voren komt in het creëeren van de string - het uiteindelijk aanpassen van de document structuur heb je buiten de timer gelaten.

mijn resultaten op AMD XP2000 win2k

nItems = 1000
IE6: 320ms
Moz1.5: 20-40ms

nItems = 2000
IE6: 1863ms
Moz1.5: 100-200ms

nItems = 3000
IE6: 4506ms
Moz1.5: 200-300ms

nItems = 4000
IE6: 8843ms
Moz1.5: 300-400ms

nItems = 5000
IE6: 14571ms
Moz1.5: 600-700ms

resultaten in Moz bij meerdere refreshes wisselen wel heel erg, IE is redelijk constant maar idd een stuk trager.
Mijn voorlopige conclusie: de IE JS implementatie kan slecht omgaan met grote strings

[ Voor 8% gewijzigd door crisp op 28-10-2003 18:40 ]

[crisp]

nog een leuke testcase (hele grote string maken):

PHP:

<html>
<head>
<title>JS Benching Machine</title>
<script type="text/javascript">

function bench() {

  var s = new Date().valueOf();

  var i = 100000;
  var a = '';
  do {

    a+='a';

  } while (i-- > 0);

  var e = new Date().valueOf();
  alert (e-s);

}

</script>
</head>
<body>
<input type="button" value="Bench" onclick="bench()" />
</body>
</html>

IE6: 20069ms
Moz 1.5: 270ms

I rest my case...

[Explore]

Gunst... 't Lijkt een stuk beter te gaan in WinXP... How weird. Ik heb hier IE 6.0.2800.1106 en Mozilla 1.4 op Win2k en krijg ongeveer dezelfde resultaten als Crisp. Toch eens kijken of gelijk schrijven naar de layer wellicht sneller werkt.

Heeft er niemand suggesties of concrete methodes om dit op te voeren???

[Bluestorm]

Dit probleem was ik een tijd terug ook al tegengekomen. Als je van plan was die string te document.write(..)'en... Dan is er voor IE een soort optimale verhouding in hoe vaak je moet writen.
Ik kwam trouwens ook ergens een stringbuffer implementatie voor javascript tegen... misschien dat dat ook nog helpt. kun je makkelijk zelf schrijven... gewoon array voor de stukjes en dan implode...

[Explore]

Bluestorm, my man! Geniaal!
Bedankt voor de tip: het werkt. IE en Mozilla zijn nu even snel!

[Explore]

Nog even wat toevoegen hieraan...

Het table-maak probleem is opgelost, maar bij een grote hoeveelheid aan Javascript-acties hangt de browser nog totdat alles klaar is. Bijvoorbeeld bij het server-side vullen van de Javascript data (JS objecten met daarin de data worden geschreven vanuit PHP) of het sorteren van een lijst.

Bij het laden van de data en tijdens het sorteren van de lijst op bepaalde items wil ik een berichtje laten zien. Maar dat wil niet werken, omdat de browser ahw. 'vast' zit.

De code is vrij simpel:

1. show message
2. sort table
3. hide message

Toch komt het berichtje niet te voorschijn.
Dit heeft volgens mij te maken met het feit dat die drie dingen achter elkaar staan en de browser pas daarna de kans weer krijgt om het scherm te verversen.

Bestaat er niet ergens een functie die de browser ahw. een schop geeft en het scherm update?

[Xanthus]

http://www.xs4all.nl/~ppk/js/innerhtml.html gaat ook over snelheid van toevoegen van informatie/tabellen, misschien wel leuk om t zien, met browservergelijkingen ed.

[crisp]

Explore schreef op 28 October 2003 @ 20:02:
[...]
Bestaat er niet ergens een functie die de browser ahw. een schop geeft en het scherm update?

ja, setTimeout - je zult dan wel een tellertje of zo moeten bijhouden

[DGTL_Magician]

Total time: 13 milliseconds

op RedHat 9 met Galeon 1.3.5
P4 2,6ghz met 512MB DDR

Voorzover je er wat aan hebt.

[Xander]

Explore schreef op 28 October 2003 @ 16:44:
[...]
Oke, ik heb een sterk versimpelde versie online gezet: http://www.davdigital.com/testcase/

OMG, ik vond IE al langzamer aanvoelen als normaal, maar dit is wel heel erg: Total time: 1232 milliseconds.

Volgens mij heb ik de langzaamste IE hier (Win 2k3).

Firebird doet het hier in 43ms.. heel stuk sneller

[slm]

IE6: 281 milliseconds
Moz1.4: 31 milliseconds
Opera7.11: 719 milliseconds
NS7.1: 46 milliseconds

Op een AMD XP 2000 op WinXP Home.

Testje van crisp: IE = 31828, Moz = 218, NS = 203 (verschillende results per keer, laagste was 187 maar 203 meest voorkomend), Opera = 56765.

Opera gaat dus met alle 2 de testen het langzaamst om.

@Explore:
probeer eens met flush() de output te flushen in php na je message en zorg dat je niet in een tabel of zo blijft steken maar die netjes afsluit voordat je verder gaat.

[paragon]

Opera 7.21 is btw stukken sneller dan 7.11. 7.21 doet er hier namelijk maar 45milliseconden over.

[Bosmonster]

Het was in IE toch stukken sneller om gewoon alle strings op te slaan in een array en dan aan het einde die in een keer met een join() samen te voegen?

Volgens mij zit je dan direct rond de performance van Mozilla.. Is imho ook niet zo heel gek.. Zelfs in PHP is bovenstaande methode sneller dacht ik.

http://www.bosmonster.nl/files/testcase2.html

Enorme performance increase voor IE (met 5000 doet ie er nu nog 150ms over) en ook nog een redelijke performance verbetering voor Mozilla (met 5000 op mijn systeem ongeveer 80ms).

Altijd aan te raden lange strings dus middels arrays en join() op te lossen

(ik gebruik trouwens push() welke niet werkt onder IE5-, maar dit is makkelijk op te lossen door zelf een teller bij te houden. Of liever om hem zelf even aan het array-prototype toe te voegen.)

[ Voor 86% gewijzigd door Bosmonster op 29-10-2003 00:09 ]

[Delphi32]

Opera 7.21 : 390 ms
IE 5.5 : 1100 ms
Hmm had ik niet verwacht, ik heb altijd de indruk dat Opera nogal traag is met JS. Valt dus nogal mee
(Systeem is P3-800 met 384 MB)

[crisp]

Het is trouwens niet alleen met strings dat IE traag is, ik heb bijvoorbeeld ook al meermalen gemerkt dat Moz vele malen sneller is met reguliere expressies en het echte Math werk. Zelfs DOM-lookups is Moz vaak sneller. Mij hoor je niet klagen over Mozilla wat dat betreft

[Explore]

Bosmonster schreef op 28 October 2003 @ 23:59:
Het was in IE toch stukken sneller om gewoon alle strings op te slaan in een array en dan aan het einde die in een keer met een join() samen te voegen?

Ja, dat is de methode die ik nu gebruik dankzij een tip hier eerder vandaag.
Werkt perfect!

(ik gebruik trouwens push() welke niet werkt onder IE5-, maar dit is makkelijk op te lossen door zelf een teller bij te houden. Of liever om hem zelf even aan het array-prototype toe te voegen.)

Als je push zelf aan 't Array-prototype toevoegt, dan komt deze method ook voorbij als je for...in gebruikt. Erg iritant. Weet je of hier wat aan te doen is? In Actionscript kan je methods hiden voor for..in loops.

slm
@Explore:
probeer eens met flush() de output te flushen in php na je message en zorg dat je niet in een tabel of zo blijft steken maar die netjes afsluit voordat je verder gaat.

Dat doe ik nu al, maar alle javascript die uitgepuugt wordt hangt de browser op: die is te druk bezig met het updaten van de objecten om nog het scherm te kunnen updaten.

Ik heb ook al gedacht aan setTimeout, maar 't probleem daar weer mee is dat deze niet werkt op objecten. Je kan niet zoiets doen:

code:

setTimeout("this.Message('hallo')", 10);

Of mis ik weer iets?

crisp
Zelfs DOM-lookups is Moz vaak sneller. Mij hoor je niet klagen over Mozilla wat dat betreft

Mozilla/Netscape is tegenwoordig (NS4 volgens mij ook al, trouwens) ook veel sneller in layer-handling, (her)positionering van (veel) div's.

[crisp]

Explore schreef op 29 October 2003 @ 01:21:
[...]
Als je push zelf aan 't Array-prototype toevoegt, dan komt deze method ook voorbij als je for...in gebruikt. Erg iritant. Weet je of hier wat aan te doen is? In Actionscript kan je methods hiden voor for..in loops.

JavaScript:

function myFunction() {
  for (var el in this) {
    if (!myObject.prototype[el]) {
      // do something
    }
  }
}

maar is idd irritant

[...]
Ik heb ook al gedacht aan setTimeout, maar 't probleem daar weer mee is dat deze niet werkt op objecten. Je kan niet zoiets doen:

code:

setTimeout("this.Message('hallo')", 10);

Of mis ik weer iets?

object reference in een global opslaan?

[McVirusS]

Niet dat het iets toevoegt aan deze thread maar ik moest ooit iets maken dat een SELECT vulde met iets van 3000 options. Als ik dit netjes via DOM-method deed hing IE gewoon halve minuut ongeveer terwijl het in Mozilla wel gewoon werkte. Bosmonster wees me toen op die array-join methode en dat bleek inderdaad de oplossing. Ineens hing IE nog maar paar seconden en in Mozilla was het ook iets sneller . Maar IE is sowieso vaag, als je een SELECT met veel options leeg wilt maken istie ook superlang bezig terwijl dit in Mozilla niet merkbaar tijd kost.

[slm]

Explore schreef op 29 October 2003 @ 01:21:
Dat doe ik nu al, maar alle javascript die uitgepuugt wordt hangt de browser op: die is te druk bezig met het updaten van de objecten om nog het scherm te kunnen updaten.

Ik heb ook al gedacht aan setTimeout, maar 't probleem daar weer mee is dat deze niet werkt op objecten. Je kan niet zoiets doen:

Mjah, geen idee hoe je die message naar voren brengt, maar ik denk aan zoiets:

PHP:

<?
// bericht opbouwen en tonen:
$message = "<div id='msgBlock'>ik ben nu erg druk bezig met allerlei zaken op te bouwen....</div>";
echo $message;
flush();

// code opbouwen en tonen:
$jscodes = "<script type='text/javascript'>blaatfuncties</script>";
echo $jscodes;

// message sluiten:
$endMsg = "<script type='text/javascript'>document.getElementById('msgBlock').style.display = 'none';</script>";
echo $endMsg;

// klaar
?>

Dat zou toch moeten werken...

[Explore]

Ja, dat is precies wat er gebeurd. Als ik weer eens tijd heb zal ik weer een test-case in elkaar flansen om het probleem aan te geven, maar helaas klopt m'n subtitel nog steeds: ik heb het ERG druk.

Probeer het anders zelf maar eens: laat PHP circa een halve Mb aan Javascript statements genereren en probeer daar tussendoor een dhtml progress-bar te updaten. Ik ben benieuwd of je dat werkend krijgt.

Note: ik heb het hier expliciet over een dhtml progress-bar, die dus met Javascript gemanipuleerd moet worden. Puur tekst met echo's naar de browser sturen gaat wel goed.

Hetzelfde geldt voor een berichtje tonen voor het sorteren van de lijst van gegevens: die komt er ook niet door.

[Bosmonster]

Op PHP/webserver output en dus browserafhankelijke interpretatie gaan bouwen wat betreft een dhtml progressbar is niet echt je van het.

Bovendien als je een progressbar nodig hebt voor een html-pagina dan zit er al iets niet helemaal goed in je interaction design

Maar als je het wilt doen, maak dan gewoon zo'n progressbar die gewoon aangeeft dat er geladen wordt, ipv dat ie ook aangeeft hoeveel die al geladen heeft van het totaal. Zo gebruikt Microsoft ze tegenwoordig ook vaak, bijvoorbeeld bij het verbinden ergens naar en je dus geen 'totaal' kunt hebben.

[ Voor 36% gewijzigd door Bosmonster op 30-10-2003 09:20 ]

[slm]

Sjah.. een progressbar is natuurlijk heel wat anders. Ik ging uit van een message aan het begin en dát is prima te doen. Je kunt natuurlijk wel met settimeout gaan werken maar dan verleng je in feite ook nog eens de tijd dat de browser bezig is en dat lijkt me niet de bedoeling.

[crisp]

slm schreef op 30 oktober 2003 @ 09:25:
Sjah.. een progressbar is natuurlijk heel wat anders. Ik ging uit van een message aan het begin en dát is prima te doen. Je kunt natuurlijk wel met settimeout gaan werken maar dan verleng je in feite ook nog eens de tijd dat de browser bezig is en dat lijkt me niet de bedoeling.

Je hoeft ook niet na elke iteratie een setTimeout te doen; stel dat je 1000 iteraties moet doen, dan kan je er ook voor kiezen elke 10 of 100 iteraties je progressbar te updaten...

[Verwijderd]

Ik heb 3 browsers getest: IE, Mozilla Firebird en Opera. Ze hebben alledrie een diferente renderengine. Ik heb elke browser drie keer de testcase laten renderen en heb telkens het beste resultaat genomen:

Mozilla:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007


Mozilla Firebird:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7


Opera:
[i]Version 7.21, Build 3218, Platform Win32


Internet Explorer:
6.0.26000


Specs:
P IV 2.4 @ 3 Ghz
1024 Mb ram
Win XP home

[ Voor 45% gewijzigd door Verwijderd op 30-10-2003 10:08 . Reden: linkfix & added mozilla browser ]