trage werking javascript IE

[Verwijderd]

Ik heb een script in een lightbox adressen toont. De gebruiker kan deze sorteren op elke kolom, verwijderen en bewerken. De adressen worden opgehaald met een ajax request. Het script binnen de lightbox is json encoded.
De meeste gebruikers gebruiken slechts een handvol adressen en daarmee is geen enkel probleem. Het wordt echter anders indien een gebruiker honderden addressen heeft (soms wel meer dan 600). In dat geval is IE6 een seconde of 30 zoet, IE8 wel een minuut, terwijl Firefox of Safari binnen 6 seconden respons geven.
Moet ik het probleem in de kwaliteit van mijn scripts zoeken, of is deze methode gewoon niet geschikt voor deze aantallen records. Of... zie ik iets over het hoofd. Nog iets.. nadat de gegevens opgehaald zijn daalt de activiteit van FF, Safari en IE6 maar 0%, terwijl IE8 pieken in CPU-load blijft geven. Script is beschikbaar via een PM

[Bosmonster]

Lijkt me niet dat het sorteren van wat rijen zo lang hoeft te duren. jQuery tablesorter bijvoorbeeld is instant.

Hoewel, ik begin me ineens af te vragen welke performance je bedoelt...

[apokalypse]

Doet nu Javascript de gegevens sorteren? Dit lijkt me geen goed schaalbare oplossing en zul problemen blijven houden met langzame browsers. Oplossing hiervoor is het sorteren aan de server kant en dit via AJAX teruggeven.

Heb je een online link?

[Bosmonster]

apokalypse schreef op maandag 23 augustus 2010 @ 17:53:
Doet nu Javascript de gegevens sorteren? Dit lijkt me geen goed schaalbare oplossing en zul problemen blijven houden met langzame browsers. Oplossing hiervoor is het sorteren aan de server kant en dit via AJAX teruggeven.

Heb je een online link?

Onzin. Als je script goed gebouwd is is het razendsnel. Een stuk sneller dan een nieuwe request.

Kijk bijvoorbeeld eens hiernaar: http://tablesorter.com

Overigens is IE sowieso extreem traag bij het laden van grote tabellen in HTML. Dat heeft verder niks met javascript te maken.

[ Voor 16% gewijzigd door Bosmonster op 23-08-2010 17:58 ]

[André]

Als het puur om de opbouw van de tabellen gaat zou je eens naar de CSS eigenschap table-layout kunnen kijken. Zet die eens op fixed om te zien of dat resultaat heeft.

<table style="table-layout:fixed">

[R4gnax]

Bosmonster schreef op maandag 23 augustus 2010 @ 17:56:
[...]
Onzin. Als je script goed gebouwd is is het razendsnel. Een stuk sneller dan een nieuwe request.

Ben ik het roerend mee eens. Zelf ooit een rich client grid geschreven die het sorteren (en filteren & pagineren) van meer dan 5000(!!) rijen in IE6 nog steeds binnen 15 seconden voor elkaar kon krijgen. Gewoon een kwestie van weten waar je mee bezig bent.

(De reden was trouwens dat destijds de tablesorter plugin zelf een rommeltje was. Steekt 'ie tegenwoordig wat beter in elkaar, Bosmonster?)

Bosmonster schreef op maandag 23 augustus 2010 @ 17:56:
Overigens is IE sowieso extreem traag bij het laden van grote tabellen in HTML. Dat heeft verder niks met javascript te maken.

Klopt. Van wat ik begrepen heb, vindt er in Trident na elke wijziging op willekeurig welk table element (td, th, tr,, etc.) een reflow en repaint van de complete table plaats. Snelle mainer om daar onderuit te komen is de hele table display: none geven, je DOM wijzigingen uit te voeren en daarna display: none weer weg te halen.

[ Voor 32% gewijzigd door R4gnax op 24-08-2010 08:54 ]

[Verwijderd]

apokalypse schreef op maandag 23 augustus 2010 @ 17:53:
Doet nu Javascript de gegevens sorteren? Dit lijkt me geen goed schaalbare oplossing en zul problemen blijven houden met langzame browsers. Oplossing hiervoor is het sorteren aan de server kant en dit via AJAX teruggeven.

Heb je een online link?

Nee kan dit niet online toegankelijk maken ivm ontbreken autorisatie, de inhoud (php/html/css/js) staat hier http://mootools.net/shell/2cKbZ/

[BtM909]

Dan lijkt het me toch handig dat je separate testcase online zet... Ik hoef je denk ik niet uit te leggen waarom we helemaal niks aan je PHP hebben?

[Verwijderd]

BtM909 schreef op dinsdag 24 augustus 2010 @ 11:11:
Dan lijkt het me toch handig dat je separate testcase online zet... Ik hoef je denk ik niet uit te leggen waarom we helemaal niks aan je PHP hebben?

Ja, dat begrijp ik, maar ik krijg daar geen toestemming voor. Ik worstel zelf wel even verder.. dank in ieder geval voor de reacties

[apokalypse]

Bosmonster schreef op maandag 23 augustus 2010 @ 17:56:
[...]
Onzin. Als je script goed gebouwd is is het razendsnel. Een stuk sneller dan een nieuwe request.

R4gnax schreef op dinsdag 24 augustus 2010 @ 08:48:
[...]
Ben ik het roerend mee eens. Zelf ooit een rich client grid geschreven die het sorteren (en filteren & pagineren) van meer dan 5000(!!) rijen in IE6 nog steeds binnen 15 seconden voor elkaar kon krijgen. Gewoon een kwestie van weten waar je mee bezig bent.
[...]

Snelheid is relatief. Via AJAX doe ik dit in 100-400ms. Dit dan exclusief rendertijd, maar blijft zeker onder de 2 sec in IE.
Plus ik zadel de gebruiker niet met verschrikkelijk hoge cpu belasting op. En alles blijft werken, want het is async.

Maar zonder testcase online wordt het inderdaad lastig zo.

[BtM909]

Verwijderd schreef op dinsdag 24 augustus 2010 @ 11:51:
[...]

Ja, dat begrijp ik, maar ik krijg daar geen toestemming voor. Ik worstel zelf wel even verder.. dank in ieder geval voor de reacties

De testcase kan je toch los van je eigen product / omgeving opzetten (het gaat toch om een bepaalde probleemstelling)? iig, als het niet kan, dan wordt 't lastig om je goed verder te helpen

[Bozozo]

Ik heb nav dit topic een table render test gemaakt. Misschien heb je er wat aan... IE is iig zo traag als dikke stront tegen de berg op als je veel DOM manipulaties doet. Je kunt dan beter innerHTML gebruiken.

[R4gnax]

apokalypse schreef op dinsdag 24 augustus 2010 @ 11:53:
Snelheid is relatief. Via AJAX doe ik dit in 100-400ms. Dit dan exclusief rendertijd, maar blijft zeker onder de 2 sec in IE.
Plus ik zadel de gebruiker niet met verschrikkelijk hoge cpu belasting op. En alles blijft werken, want het is async.

5000 rijen was dan ook een extreem pessimistische case, hè? Met 500 rijen is het al (ongeveer) een factor 10 sneller en in de orde van grootte v/d pessimistiche case voor de TS (600 addressen).

Trouwens, zelfs onder IE7 deed mijn script er al significant korter over. (50% sneller, geloof ik?) Dus het punt dat je dit goed clientside kunt doen staat nog steeds: Alleen de oude IE6 zou nl. relatief 'lang' moeten wachten en sorry, maar als je nog met IE6 browst ben je waarschijnlijk toch al gewend te moeten wachten. Om voor die ene oude browser nou een complete client-server interactie op te gaan zetten m.b.v. XmlHttpRequests ...

[apokalypse]

R4gnax schreef op dinsdag 24 augustus 2010 @ 13:07:
[...]


5000 rijen was dan ook een extreem pessimistische case, hè? Met 500 rijen is het al (ongeveer) een factor 10 sneller en in de orde van grootte v/d pessimistiche case voor de TS (600 addressen).

Trouwens, zelfs onder IE7 deed mijn script er al significant korter over. (50% sneller, geloof ik?) Dus het punt dat je dit goed clientside kunt doen staat nog steeds: Alleen de oude IE6 zou nl. relatief 'lang' moeten wachten en sorry, maar als je nog met IE6 browst ben je waarschijnlijk toch al gewend te moeten wachten. Om voor die ene oude browser nou een complete client-server interactie op te gaan zetten m.b.v. XmlHttpRequests ...

Je moet het zelf weten maar IMO is Javascript geen goede oplossing voor zulk intensief werk wat makkelijk een server kan doen.

[R4gnax]

apokalypse schreef op dinsdag 24 augustus 2010 @ 14:57:
[...]

Je moet het zelf weten maar IMO is Javascript geen goede oplossing voor zulk intensief werk wat makkelijk een server kan doen.

Het gaat er niet om of de server het makkelijker kan doen, het gaat er om of de extra bijkomende kosten (nu voor implementatie en in de toekomst voor maintenance) van het asynchroon inladen en hersorteren van een tabel de moeite waard zijn ten opzichte van een drop-in javascript oplossing die alleen een noemenswaardige vertraging zal hebben onder het wandelende lijk dat Internet Explorer 6 heet. Afhankelijk van details rondom de implementatie kan dat namelijk toch een behoorlijk niet-triviale wijziging zijn aan de server side.


Trouwens, wat betreft performance en CPU gebruik: je kunt een beetje intelligente clientside sorting plugin ook nog met wat setTimeout trucage zichzelf laten time-slicen, zodat hij je CPU niet 100% spiked en onder moderne browsers kun je de interne data manipulaties ook nog eens op een asynchroon worker process afladen. Javascript is wat dat betreft echt niet meer het kleutertaaltje dat het ten tijde van IE4 of zo was.

[apokalypse]

Bosmonster schreef op maandag 23 augustus 2010 @ 17:56:
[...]


Onzin.

Het is een mening, daarom staat er ook "Dit lijkt me"

Javascript is wat dat betreft echt niet meer het kleutertaaltje dat het ten tijde van IE4 of zo was.

Klopt, maar hier is het niet voor gebouwd. Maar als schaalbaar niet belangrijk is en hacks geen probleem zijn (timeout), dan moet je gerust Javascript hiervoor gebruiken.

[pieturp]

apokalypse schreef op dinsdag 24 augustus 2010 @ 21:14:
[...]
Klopt, maar hier is het niet voor gebouwd.
[...]

Met zo'n instelling komen we nooit verder natuurlijk. Waarom denk je dat er zo ontzettend veel tijd en energie wordt gestoken in de ontwikkeling van nieuwe engines?
Juist! Omdat JavaScript er tegenwoordig wél voor wordt gebruikt

Da's trouwens al lang mogelijk hoor!

[Bosmonster]

Het realtime sorteren van dit soort gegevens is een interface actie, dus dit hoort gewoon clientside te gebeuren.

Dit is dus juist precies waar javascript voor bedoeld is. Zodat je voor onbenulligheden als het sorteren van wat data en DOM-manipulaties niet meer de server in hoeft te schakelen.

Het probleem zit hem dan ook niet in of javascript hiervoor bedoeld is, want daar ligt de bottleneck helemaal niet (het sorteren in javascript is microseconde-werk). Het probleem zit hem in antieke browsers die te traag zijn met het verwerken van DOM-updates.

Bozozo schreef op dinsdag 24 augustus 2010 @ 12:40:
Ik heb nav dit topic een table render test gemaakt. Misschien heb je er wat aan... IE is iig zo traag als dikke stront tegen de berg op als je veel DOM manipulaties doet. Je kunt dan beter innerHTML gebruiken.

Volgens mij kun je aan de innerHTML-methode nog wat optimaliseren door een Array te gebruiken ipv string-concatenatie.

Het probleem met tabellen is dat het enorm veel elementen zijn, dus zelfs met snelle browsers is het injecteren van HTML bijna altijd sneller.

edit: array gebruiken ipv string-concatenatie haalt nog eens zo'n 30-40% van de tijd af in Webkit (helaas even geen IE hier om te testen).

[ Voor 98% gewijzigd door Bosmonster op 25-08-2010 00:27 ]

[pieturp]

Nevermind!

[ Voor 96% gewijzigd door pieturp op 25-08-2010 02:01 . Reden: Beter lezen... ]

[apokalypse]

pieturp schreef op dinsdag 24 augustus 2010 @ 22:57:
[...]


Met zo'n instelling komen we nooit verder natuurlijk.

En met zo'n instelling krijg je schaalbaarheid problemen terwijl de server dit zonder enig probleem oppakt. Misschien moeten we alle server scripts dan ook maar afschaffen, dit kan ook bij met JS.

Naar mijn mening wordt de complexiteit van sorteren onderschat en valt deze soort dure bewerkingen echt niet bij het doel van Javascript.

Waarom denk je dat er zo ontzettend veel tijd en energie wordt gestoken in de ontwikkeling van nieuwe engines?
Juist! Omdat JavaScript er tegenwoordig wél voor wordt gebruikt

Dit heeft er waarschijnlijk meer mee te maken dat mensen dingen doen waar ze geen verstand van hebben, maar copy-pasten van een scriptje nog wel lukt. Met die reden zouden we allemaal weer terug moeten gaan naar quirksmode

[ Voor 36% gewijzigd door apokalypse op 26-08-2010 14:10 ]

[Styxxy]

apokalypse schreef op donderdag 26 augustus 2010 @ 14:07:
[...]
En met zo'n instelling krijg je schaalbaarheid problemen terwijl de server dit zonder enig probleem oppakt. Misschien moeten we alle server scripts dan ook maar afschaffen, dit kan ook bij met JS.

Naar mijn mening wordt de complexiteit van sorteren onderschat en valt deze soort dure bewerkingen echt niet bij het doel van Javascript.

Ik denk dat het verhaal niet zo zwart-wit is zoals jullie willen voorstellen. Beide mogelijkheden (sorteren server- of client-side) zijn valide mogelijkheden en ook bruikbaar. Het hangt er enkel vanaf in wat voor context dat je bezig bent. Je moet dus de context bepalen vooraleer je voor een methode gaat kiezen.

Indien je veel data moet sorteren, kan je beter server-side gaan sorteren, aangezien die daar inderdaad beter op voorzien is. Zoals de TS zijn probleem, erg grote tabellen zijn intensief om te sorteren en kunnen dus beter niet bij de client gebeuren.

Daarentegen, als je over een beperkte dataset beschikt (kleinere tabellen), kan de client dit perfect afhandelen. Zo hoef je jouw server hiervoor niet lastig te vallen (alsook eventueel je applicatie uit te breiden om dit mogelijk te maken).

[R4gnax]

apokalypse schreef op donderdag 26 augustus 2010 @ 14:07:
En met zo'n instelling krijg je schaalbaarheid problemen terwijl de server dit zonder enig probleem oppakt. Misschien moeten we alle server scripts dan ook maar afschaffen, dit kan ook bij met JS.

Naar mijn mening wordt de complexiteit van sorteren onderschat en valt deze soort dure bewerkingen echt niet bij het doel van Javascript.

Puur het sorteren van items gaat heel, heel snel. Alleen het verversen van de DOM duurt lang(er) en juist die kosten zou je met een AJAX oplossing ook nog gewoon hebben. (Overigens is sorteren maar een gewone O(n log n) operatie hoor. Daar valt weinig aan te onderschatten.)

apokalypse schreef op donderdag 26 augustus 2010 @ 14:07:
Dit heeft er waarschijnlijk meer mee te maken dat mensen dingen doen waar ze geen verstand van hebben, maar copy-pasten van een scriptje nog wel lukt. Met die reden zouden we allemaal weer terug moeten gaan naar quirksmode

Eerder omgekeerd: javascript vermijden voor dit soort zaken heeft te maken met mensen die het niet efficient kunnen programmeren en/of hun menig enkel baseren op inefficiente, oude scripts die ze in een grijs verleden eens hebben lopen copy-pasten.

[Bosmonster]

Idd.. mijn bek valt een beetje open van de anti-JS meningen en geven duidelijk aan dat er nauwelijks javascriptkennis aanwezig is.

De bottleneck, zoals ik al eerder zei, ligt helemaal niet in je JS-verwerking, maar in de DOM-verwerking. Of je het nu serverside sorteert en de data nog een keer door laat sturen of je doet het clientside, die DOM-verwerking kom je niet omheen.

Uiteindelijk is je serverside oplossing dus een stuk trager dan de clientside oplossing.

[apokalypse]

[b][message=34587782,noline]
Eerder omgekeerd: javascript vermijden voor dit soort zaken heeft te maken met mensen die het niet efficient kunnen programmeren en/of hun menig enkel baseren op inefficiente, oude scripts die ze in een grijs verleden eens hebben lopen copy-pasten.

Grapjurk. Een goede schaalbaarheid haal je niet met Javascript. Dat wordt hier ook bewezen, want eerst ging het over 5000 rijen en toen opeens maar over 500.

Idd.. mijn bek valt een beetje open van de anti-JS meningen en geven duidelijk aan dat er nauwelijks javascriptkennis aanwezig is.

Knap dat het mij dan wel in 2 sec lukt in IE6. Zonder hoge CPU van de client.

[pieturp]

Nou haal je dus wéér de snelheid van de DOM en die van JavaScript door elkaar

[crisp]

apokalypse schreef op donderdag 26 augustus 2010 @ 14:07:
[...]

Naar mijn mening wordt de complexiteit van sorteren onderschat en valt deze soort dure bewerkingen echt niet bij het doel van Javascript.

Je onderschat javascript schromelijk

apokalypse schreef op donderdag 26 augustus 2010 @ 20:25:
[...]

Knap dat het mij dan wel in 2 sec lukt in IE6. Zonder hoge CPU van de client.

Da's dan alleen puur de rendering (wat een browser ongeacht de methode sowieso moet doen). Daarbij is IE6 totaal geen maatstaf; IE6 heeft gewoon een ontzettend trage javascript engine en is qua snelheid al jaren geleden voorbij gestreeft, en qua marktaandeel trouwens ook

Sterker nog, en om mijn eerste opmerking te beargumenteren: er zijn javascript engines die sneller sorteren dan bijvoorbeeld PHP het kan.

Wat resultaten van een script dat een array met 100.000 elementen genereert gevuld met random getallen en dat eerst met PHP en vervolgens met javascript sorteert, uitgevoert in verschillende browsers op een (oude) P4 2.8Ghz met windows XP:

PHP (versie 5.3.1): +/- 310ms

Chrome 5.0: +/- 130ms
Opera 10.61: +/- 250ms
Firefox 3.5.11: +/- 450ms (3.6 even niet voorhanden)
IE8: +/- 1900ms

En zowel Microsoft, Mozilla als Opera zijn bezig met javascript engines die qua snelheid richting die van Chrome's V8 gaan, dus over ongeveer een jaar kloppen alle mainstream browsers PHP op dit punt (tenzij PHP op dit punt sterk verbetert )

Hier mijn q&d testscript:

PHP:

<?php

$a = array();
$i = 100000;
while ($i--)
    $a[] = mt_rand(0, 1000000);

echo '<script type="text/javascript">var a=[' . implode(',', $a) . '];</script>';

$s = microtime(true);
sort($a, SORT_NUMERIC);
$e = microtime(true);

echo 'PHP: ' . round(($e - $s) * 1000) . 'ms<br>';

?>
<script type="text/javascript">

function cmp(a,b)
{
    return a - b;
}

var s = new Date().getTime();
a.sort(cmp);
var e = new Date().getTime();

document.write('JavaScript: ' + (e - s) + 'ms');

</script>

note dat javascript zelfs nog een compare functie nodig heeft voor getallen; de default sortering van de sort() method is namelijk lexicografisch en er is geen native sorteer method voor numerieke sortering(!)

Als ik het omdraai, en als string ga sorteren, dan komen er helemaal andere getallen uit (en zijn Firefox en Opera ineens het snelste):

PHP: +/- 2200ms(!)
Opera: +/- 220ms
Firefox: +/- 240ms
Chrome: +/- 400ms
IE8: +/- 1000ms

Conclusie: PHP's sorteeralgoritme is gewoon traag en javascript doet het zo slecht nog niet; dit gaat immers wel over een array met 100.000 items en niet 500 of 5000...

[ Voor 10% gewijzigd door crisp op 26-08-2010 23:27 ]

[Woy]

crisp schreef op donderdag 26 augustus 2010 @ 23:02:
[...]
Conclusie: PHP's sorteeralgoritme is gewoon traag en javascript doet het zo slecht nog niet; dit gaat immers wel over een array met 100.000 items en niet 500 of 5000...

Maar zolang niet hetzelfde sorteer algoritme gebruikt is het natuurlijk niet echt een eerlijke vergelijking. Ik vraag me zelfs af of alle javascript engines wel hetzelfde sorteer algoritme gebruiken.

Op deze manier ben je eigenlijk gewoon sorteer algoritmes aan het vergelijken, en niet zozeer javascript vs php

[crisp]

Woy schreef op vrijdag 27 augustus 2010 @ 09:39:
[...]

Maar zolang niet hetzelfde sorteer algoritme gebruikt is het natuurlijk niet echt een eerlijke vergelijking. Ik vraag me zelfs af of alle javascript engines wel hetzelfde sorteer algoritme gebruiken.

Op deze manier ben je eigenlijk gewoon sorteer algoritmes aan het vergelijken, en niet zozeer javascript vs php

Dat boeit niet Het ging om de stelling dat sorteren een dure operatie zou zijn en dus per definitie serverside uitgevoerd zou moeten worden omdat javascript daar niet geschikt voor zou zijn. Ik concludeerde daarom al dat PHP in ieder geval blijkbaar een slechter algoritme heeft dan een aantal javascript engines, maar dat in het algemeen de performance van javascript mbt sorteren gewoon goed te noemen is (hoewel IE daarin wat achterloopt ten opzichte van de andere browsers) en er dus geen echte reden is om daar geen javascript voor te gebruiken

[ Voor 4% gewijzigd door crisp op 27-08-2010 09:44 ]

[NetForce1]

Hoe snel sorteren in JS ook is, het kan nog steeds een valide keuze zijn om het sorteren aan de server over te laten. Simpelweg omdat er anders te veel data over de lijn moet, of omdat het de server veel tijd kost om de resultaten uit de back-end te halen.

[Bosmonster]

NetForce1 schreef op vrijdag 27 augustus 2010 @ 09:52:
Hoe snel sorteren in JS ook is, het kan nog steeds een valide keuze zijn om het sorteren aan de server over te laten. Simpelweg omdat er anders te veel data over de lijn moet, of omdat het de server veel tijd kost om de resultaten uit de back-end te halen.

Huh? Je noemt nu twee argumenten om het juist _niet_ via de server te doen? (onnodige dataverkeer en serverbelasting)

[ Voor 4% gewijzigd door Bosmonster op 27-08-2010 09:55 ]

[NetForce1]

Bosmonster schreef op vrijdag 27 augustus 2010 @ 09:54:
[...]
Huh? Je noemt nu twee argumenten om het juist _niet_ via de server te doen? (onnodige dataverkeer en serverbelasting)

Hoezo? Stel dat het vijf minuten zou kosten om de complete dataset naar de client te sturen, terwijl sorteren op de server en dan opsturen in een paar ms gepiept is dan weet ik wel wat ik zou kiezen.

[Puc van S.]

NetForce1 schreef op vrijdag 27 augustus 2010 @ 09:58:
[...]

Hoezo? Stel dat het vijf minuten zou kosten om de complete dataset naar de client te sturen, terwijl sorteren op de server en dan opsturen in een paar ms gepiept is dan weet ik wel wat ik zou kiezen.

In beide gevallen moet toch de complete dataset naar de client gestuurd worden?

[NetForce1]

M1lamb3r schreef op vrijdag 27 augustus 2010 @ 10:00:
[...]
In beide gevallen moet toch de complete dataset naar de client gestuurd worden?

Niet als met pagination oid gewerkt wordt.

[Verwijderd]

NetForce1, je spreekt jezelf weer tegen. Je zegt nu dat het bijvoorbeeld vijf minuten kost om het naar de client te sturen. Daarna zeg je dat het opsturen in een paar ms gepiept is.

Of lees ik het nu krom?

edit: de reactie over pagination stond er nog niet

[ Voor 12% gewijzigd door Verwijderd op 27-08-2010 10:09 ]

[NetForce1]

Verwijderd schreef op vrijdag 27 augustus 2010 @ 10:05:
NetForce1, je spreekt jezelf weer tegen. Je zegt nu dat het bijvoorbeeld vijf minuten kost om het naar de client te sturen. Daarna zeg je dat het opsturen in een paar ms gepiept is.

Of lees ik het nu krom?

Ik was in die post vergeten te vermelden dat slechts een subset van de totale dataset opgestuurd omdat de client met pagination oid werkt.

[Bosmonster]

Maar dan kom je op een heel ander probleem, namelijk dat je sowieso geen duizenden records naar de client wil versturen.

En dat heeft weinig met performance te maken, maar des te meer met usability

Paginering in dat soort gevallen is overigens ook niet echt aan te raden. Een gebruiker zegt het niks of iets pagina 3 of 4 is als die niet weet wat er op die pagina staat. Dan kun je beter een index, search of filtersysteem introduceren ipv domweg al je records te pagineren.

[ Voor 40% gewijzigd door Bosmonster op 27-08-2010 10:12 ]

[Woy]

crisp schreef op vrijdag 27 augustus 2010 @ 09:43:
[...]

Dat boeit niet Het ging om de stelling dat sorteren een dure operatie zou zijn en dus per definitie serverside uitgevoerd zou moeten worden omdat javascript daar niet geschikt voor zou zijn. Ik concludeerde daarom al dat PHP in ieder geval blijkbaar een slechter algoritme heeft dan een aantal javascript engines, maar dat in het algemeen de performance van javascript mbt sorteren gewoon goed te noemen is (hoewel IE daarin wat achterloopt ten opzichte van de andere browsers) en er dus geen echte reden is om daar geen javascript voor te gebruiken

Daar ben ik het wel mee eens hoor, maar wilde even benadrukken dat het niet perse PHP zelf is dat langzaam is, maar waarschijnlijk gewoon het sorteer algoritme.

Overigens is de vergelijking tussen de verschillende browsers sowieso niet helemaal eerlijk, aangezien je telkens een andere random dataset hebt, het kan zijn dat de een toevallig een minder gunstige situatie heeft, al zal dat in de praktijk waarschijnlijk wel meevallen. Een betere test zou zijn om een random met een vaste seed te nemen.

[NetForce1]

Bosmonster schreef op vrijdag 27 augustus 2010 @ 10:11:
Maar dan kom je op een heel ander probleem, namelijk dat je sowieso geen duizenden records naar de client wil versturen.

En dat heeft weinig met performance te maken, maar des te meer met usability

Waarom zou dat niet met performance te maken hebben? Waarom denk je dat in een product als Google Reader (of Google Search) niet alle resultaten ineens naar de client gestuurd worden?
Overigens kan ipv pagination ook bijv. de data opgehaald worden als de user scrollt, dus je usablity-punt zie ik niet echt.

[Bosmonster]

NetForce1 schreef op vrijdag 27 augustus 2010 @ 10:16:
[...]

Waarom zou dat niet met performance te maken hebben? Waarom denk je dat in een product als Google Reader (of Google Search) niet alle resultaten ineens naar de client gestuurd worden?

Omdat dat een hele andere insteek is, aangezien je het hier niet hebt over vaste sorteerbare resultsets (waar dit topic over gaat).

Overigens kan ipv pagination ook bijv. de data opgehaald worden als de user scrollt, dus je usablity-punt zie ik niet echt.

Load-on-scroll is inderdaad een optie, maar niet altijd. Bij vaste resultsets bijvoorbeeld niet en al helemaal niet als je kunt sorteren. Dit werkt dus vooral bij resultaten waarbij het einde niet bekend is (zoals Google Search).

Geen appels met peren vergelijken

Overigens lijkt het me wat dat betreft wel eens erg interessant een test te zien met een forum zoals GoT, waarbij de paginering overboord gegooid wordt voor topics. Veel interessanter is daar een index op datum/tijd bijvoorbeeld. Dan hoef je ook niet meer iedere 1000 posts een nieuw topic te maken, wat natuurlijk ook killing is voor de zoekbaarheid. Ik stoor me regelmatig aan de complete willekeur van paginering. Maar dat is nogal een heftige ingreep in het systeem

[ Voor 21% gewijzigd door Bosmonster op 27-08-2010 10:26 ]

[NetForce1]

Bosmonster schreef op vrijdag 27 augustus 2010 @ 10:20:
[...]
Omdat dat een hele andere insteek is, aangezien je het hier niet hebt over vaste sorteerbare resultsets (waar dit topic over gaat).
[...]
Load-on-scroll is inderdaad een optie, maar niet altijd. Bij vaste resultsets bijvoorbeeld niet en al helemaal niet als je kunt sorteren. Dit werkt dus vooral bij resultaten waarbij het einde niet bekend is (zoals Google Search).

Geen appels met peren vergelijken

Google Search was misschien niet helemaal een goed voorbeeld, maar bij Reader heb je het wel over een vaste result set lijkt me toch.

[Bosmonster]

NetForce1 schreef op vrijdag 27 augustus 2010 @ 10:25:
[...]

Google Search was misschien niet helemaal een goed voorbeeld, maar bij Reader heb je het wel over een vaste result set lijkt me toch.

Je hebt het bij Reader over een chronologische set, waarbij de laatste dus interessant zijn en hoe verder weg hoe minder. Waarschijnlijk heb je bij Reader ook gewoon een goede search-mogelijkheid, aangezien niemand op basis van de paginering daadwerkelijk iets gaan vinden.

Paginering is voor browsen, niet voor zoeken. Daar moet je dus erg op letten als je een resultset aan de gebruiker aanbiedt, of browsen uberhaupt wel van toepassing is op je gegevens.

Als je een resultset hebt waar mensen in kunnen zoeken en sorteren, is paginering dus een hele inefficiente manier van aanbieden. Want stel, ik heb 30 pagina's, kan sorteren op alfabet en moet bij de P zijn. Dan mag ik willekeurig maar wat pagina's aan gaan klikken en hopen dat ik ergens bij de P terecht kom

[ Voor 17% gewijzigd door Bosmonster op 27-08-2010 10:31 ]

[crisp]

Woy schreef op vrijdag 27 augustus 2010 @ 10:14:
[...]

Daar ben ik het wel mee eens hoor, maar wilde even benadrukken dat het niet perse PHP zelf is dat langzaam is, maar waarschijnlijk gewoon het sorteer algoritme.

Dat zal inderdaad wel het geval zijn; het is dan misschien ook interessant om eens te kijken hoe andere serverside talen het er van afbrengen:)

Overigens is de vergelijking tussen de verschillende browsers sowieso niet helemaal eerlijk, aangezien je telkens een andere random dataset hebt, het kan zijn dat de een toevallig een minder gunstige situatie heeft, al zal dat in de praktijk waarschijnlijk wel meevallen. Een betere test zou zijn om een random met een vaste seed te nemen.

Ik zag bij meerdere runs in de verschillende browsers geen grote afwijkingen in sorteertijd, dus dat effect is imo te verwaarlozen

[apokalypse]

pieturp schreef op donderdag 26 augustus 2010 @ 21:13:
Nou haal je dus wéér de snelheid van de DOM en die van JavaScript door elkaar

Incl in DOM zetten.

@crisp: ja int sorteren, nu strings

[pieturp]

crisp schreef op donderdag 26 augustus 2010 @ 23:02:
[...]
Als ik het omdraai, en als string ga sorteren, dan komen er helemaal andere getallen uit (en zijn Firefox en Opera ineens het snelste):

PHP: +/- 2200ms(!)
Opera: +/- 220ms
Firefox: +/- 240ms
Chrome: +/- 400ms
IE8: +/- 1000ms

Conclusie: PHP's sorteeralgoritme is gewoon traag en javascript doet het zo slecht nog niet; dit gaat immers wel over een array met 100.000 items en niet 500 of 5000...