Skript in IE um 600% zu langsam

[ComputerPadawan]

Hallo!

Ich habe hier ein Skript, welches dazu dient den Inhalt einer Datenbanktabelle im Browser in einer per Javascript

Sortierbaren Tabelle darzustellen. Dazu lade ich mit PHP den Datenbankinhalt in Javascript Arrays und verspachtele

diese dann mit Sortierfunktionen um das Ergebnis über document.write auszugeben.

Klappt auch eigentlich ganz alles ganz gut. Zumindest so lange bis meine Datenbank eine kritische Größe erreicht.

(Liegt ja in der Natur der Sache). Überrascht war ich darüber wo diese Größe beim IE zu liegen scheint:

2D-Array mit 1848 Feldern.

Das erstellen der Siete mit PHP und das laden der JAvaScript Arrays geht echt fix. Genauso das sortieren der Einträge

(insgesamt was in der Größenordnung 20-30ms).

Aber das darstellen!

Ich reduzierte die Codezeilen also auf ein Minimum

[CODE]

...
for(var i = 0; i < Zeilen; ++i)//Zeilen -> Anzahl der darzustellenden Zeilen (im Beispiel ca. 800)
{
  ...
  if(!not) //Sofern die betreffende Zeile überhaupt angezeigt werden soll
  {
    ...
    var jetzt = new Date();
    Timebase = jetzt.getTime();

for(var j=0; j<spalten;++j) //Spalten -> Anzahl der darzustellenden Spalten (im Beispiel 6)
    {
      tab += "<td> NOPE </td>";
    }

var jetzt = new Date();
    Time=jetzt.getTime();
    TimeC=TimeC+(Time-Timebase);

...
  }
  ...
}
...
//Und später wird "tab" je nach Verfügbarkeit entweder mit "innerHTML" oder "document.write" ausgegeben
[/CODE]

und bekam diese Ergebnisse für TimeC:
IE                 9526ms
Netscape         15ms
Opera              <1ms

Während der IE läuft habe ich übrigends eine CPU-Last von 100%. Er tut also wirklich was.

Ich werden de ganze Code umstricken müssen, weil das Skript für eine Intranetapplikation im IE umfeld gedacht ist. Aber

dazu müsste ich ersteinmal verstehen wo dieser eklatante Laufzeitunterschied herkommt.

Ich wusste ja, das Opera schnell ist, aber ist der IE wirklich so langsam? Oder serviere ich nur IE unverträglichen

Code? Aber kann das bei den paar Zeilen überhaupt sein?

Hatte jemand schonmal so ein problem, oder kann es sich einer von euch irgendwie erklären?

Es hoft auf Antwort, euer
Coputer Padawan

[wahsaga]

hi,

könntest du bitte ohne die vielen unnötigen Leerzeilen posten? Danke.

Und später wird "tab" je nach Verfügbarkeit entweder mit "innerHTML" oder "document.write" ausgegeben

Das dürften nicht unbedingt die schnellsten Möglichkeiten sein.

Hatte jemand schonmal so ein problem, oder kann es sich einer von euch irgendwie erklären?

Da möchte ich dir den recht interessanten und aufschlussreichen Artikel Dynamic HTML Tables: Improving Performance empfehlen.

Der vergleicht mehrere Methoden, eine Tabelle dynamisch aufzubauen, in Bezug auf die Performance in unterschiedlichen Browsern.

Ich werden de ganze Code umstricken müssen, weil das Skript für eine Intranetapplikation im IE umfeld gedacht ist.

Dann kannst du dir ja den Ansatz rauspicken, der für den IE der performanteste ist.

gruß,
wahsaga

[ComputerPadawan]

Danke! Auf den ersten Blick sieht das wirklich sehr hilfreich aus.

Ich habe schlechte erfahrungen mit dem posten langer Beiträge gemacht, deshalb schreibe ich sie immer als textdatei vor und kopiere dann. Ich werde in Zukunft darauf achten, dass dabei nicht so viele Leerzeilen entstehen.

[Struppi]

Ich habe hier ein Skript, welches dazu dient den Inhalt einer Datenbanktabelle im Browser in einer per Javascript

Sortierbaren Tabelle darzustellen. Dazu lade ich mit PHP den Datenbankinhalt in Javascript Arrays und verspachtele

diese dann mit Sortierfunktionen um das Ergebnis über document.write auszugeben.

Klappt auch eigentlich ganz alles ganz gut. Zumindest so lange bis meine Datenbank eine kritische Größe erreicht.

Deine Absatzformatierungen sind gewöhnungsbedürftig, warum trennst du Sätze mit einem Absatz?

(insgesamt was in der Größenordnung 20-30ms).

Aber das darstellen!

Ich reduzierte die Codezeilen also auf ein Minimum

[CODE]

Was willst du jetzt genau Wissen, dass was du uns zeigst, wird kaum 9 sekunden dauern.

Wenn ich dein Beispiel in funktionierenden code überführe, dauert er hier auf einem UrUralt rechner (mit IE 4) ca. 0 - 60 ms
und erst wenn ich die werte für Zeilen und spalten (übrigens sollte man Variabelnnamen konsistent deklarieren, entweder alle Groß oder alle Klein [was für Variabeln der Standard wäre] ) dramatisch erhöhe bekomme ich überhaupt eine meßbare Zeitverzögerung.

  
var Zeilen = 8000;  
var spalten = 60;  
var not = true;  
var tab = '';  
  
var vorher = new Date();  
for(var i = 0; i < Zeilen; ++i)//Zeilen -> Anzahl der darzustellenden Zeilen (im Beispiel ca. 800)  
{  
  if(!not) //Sofern die betreffende Zeile überhaupt angezeigt werden soll  
  {  
  
    for(var j=0; j<spalten;++j) //Spalten -> Anzahl der darzustellenden Spalten (im Beispiel 6)  
    {  
      tab += "<td> NOPE </td>";  
    }  
  }  
}  
var jetzt = new Date();  
alert( jetzt - vorher );  

Struppi.

[ComputerPadawan]

Sorry wegen der Absatztrennung, wie in der Antwort auf wahsagas Post schon schrieb: Ich schreibe üblicherweise alls erstmal als Textdatei und kopiere dann in die Eingabemaske. Dabei scheint was schiefgegangen zu sein. Ich werde mich bessern.

Wenn ich dein Beispiel in funktionierenden code überführe, dauert er hier auf einem UrUralt rechner (mit IE 4) ca. 0 - 60 ms
und erst wenn ich die werte für Zeilen und spalten (übrigens sollte man Variabelnnamen konsistent deklarieren, entweder alle Groß oder alle Klein [was für Variabeln der Standard wäre] ) dramatisch erhöhe bekomme ich überhaupt eine meßbare Zeitverzögerung.

Leider liegt hier ein kommunikationsfehler zwischen uns vor: Das "not" ist in den meisten Fällen erstmal "true" (es sei denn es wurde ein Inhaltsfilter gesetzt, was beim ersten Aufruf nie der Fall ist). Diese Änderung genügt in meinen test schon wieder um mit der Laufzeit durchs Dach zu schießen.

[Struppi]

Leider liegt hier ein kommunikationsfehler zwischen uns vor: Das "not" ist in den meisten Fällen erstmal "true" (es sei denn es wurde ein Inhaltsfilter gesetzt, was beim ersten Aufruf nie der Fall ist). Diese Änderung genügt in meinen test schon wieder um mit der Laufzeit durchs Dach zu schießen.

Das hatte ich übersehen, not ist false der Vegleich !not sollte true ergeben. Stimmt es sieht so aus als ob der IE Stringverknüpfungen extrem langsam macht.

Struppi.

[Struppi]

Ich kann eine erhebliche Verbesserung erzielen, indem ich in der inneren Schleife einen temporären String verwende:

  
  if(!not) //Sofern die betreffende Zeile überhaupt angezeigt werden soll  
  {  
  
    var tmp = '';  
    for(var j=0; j<spalten;++j) //Spalten -> Anzahl der darzustellenden Spalten (im Beispiel 6)  
    {  
      tmp += "<td> NOPE </td>";  
    }  
  }  
  tab += tmp;  

hier (bei 400 x 6 ) von ca 1700ms zu ca. 380ms

Struppi.

[ComputerPadawan]

Es scheint wirklich ausschließlich am ineffizienten zeichenkettenhandling des InternetExplorers zu liegen. Ich kann Diene Laufzeitwerte bestätigen. Bei meinem 800x6 Testaufbau verringerte deine Methode die Wartezeit von 8300ms auf 1500ms. Das ist zwar schon was, ist aber dennoch unendlich weit von den Werten von Opera und Netscape weg und für den Anwender auch nicht wirklich "Flüssig" (zumal die Lösung noch zu mehr Datensaätzen skalierbar sein sollte).

Eine Umstellung von += auf .concat() bewirkte eine minimale Verlangsamung.

Die Einzige Möglichkeit die ich noch sah war es nicht zuerst in einen String zu schreiben, sondern direkt über DOM einzufügen. Eigentlich Schade, da ich gerade eine so schön Browserunabhängige und (abgesehen vom IE) schnelle Lösung gefunden hatte :´(

!!!LÖSUNG!!!

Dann habe ich nochwas anderes versucht: Zuerst alles in ein Array schreiben und dann mit .join(" ") umwandeln lassen. Und siehe da: Die Schleife dauert nurnoch 16ms, das Umwandeln 47ms und insgesamt bin ich so trotz des zusätzlichen Schritts mit 63ms in Schalgweite zu Opera und Netscape.

Opera bleibt (für Beide Schritte) <1ms und Netscape braucht jeweils 62ms, was im Ergebnis noch tragbar ist.

[Struppi]

!!!LÖSUNG!!!

Dann habe ich nochwas anderes versucht: Zuerst alles in ein Array schreiben und dann mit .join(" ") umwandeln lassen. Und siehe da: Die Schleife dauert nurnoch 16ms, das Umwandeln 47ms und insgesamt bin ich so trotz des zusätzlichen Schritts mit 63ms in Schalgweite zu Opera und Netscape.

Das erstaunt mit (ich kamn es aber nur bestätigen), denn ich hab diese Methode in Perl, in einer ähnlichen Situtation, wieder verworfen, da sie dort langsamer war.

Gut zu Wissen

Struppi.

[Ashura]

Hallo Struppi.

Dann habe ich nochwas anderes versucht: Zuerst alles in ein Array schreiben und dann mit .join(" ") umwandeln lassen. […]

Das erstaunt mit (ich kamn es aber nur bestätigen), denn ich hab diese Methode in Perl, in einer ähnlichen Situtation, wieder verworfen, da sie dort langsamer war.

Auf Quirksmode.org gibt es dazu sogar Benchmarks.

Einen schönen Mittwoch noch.

Gruß, Ashura

[JürgenB]

Hallo ComputerPadawan,

dass das Sortieren von Tabellen mit Javascript nicht sehr schnell geht, habe ich auch schon feststellen müssen. Deine Zahlen kann ich aber nicht nachvollziehen. Bei mir braucht der IE etwa 1.5 bis 2-mal so lange, wie der FF. Siehe http://www.uni-muenster.de/Physik.AP/Buecher-de.html. Achtung, ca. 1MB groß. Hier werden fast 3000 Zeilen mit 3 Spalten sortiert.

Mein Tabellensortierer liest und beschreibt die Tabellenfelder mit innerHTML, da ich in einer anderen Tabelle auch Felder mit Text und Bild habe.

Gruß, Jürgen

[ComputerPadawan]

Die Lösung ist gefunden,

Sie ist nicht perfekt, aber ohne Frage akzeptabel. (siehe mein Posting vom 08.03.2006, 14:21: http://forum.de.selfhtml.org/?t=125177&m=806954)

Für die gemeinsam gefundene Antwort dankt den Helfern JürgenB, Wahsaga und besonders Struppi

Coputer Padawan