Jetzt funzt es: Kopf wird angezeigt, danach de Tabelle

[Rolf B]

Hallo Linuchs,

habe gerade selbst noch was in einem Fiddle getestet, mit einem primitiven CSV String und 10000 Rows (sonst ging es zu schnell :) )

Es ist die gleiche Erfahrung wie bei Dir: Zeit X für das Aufbauen des HTML, Zeit Y für das Zuweisen an innerHTML - das löst das Parsen des HTML und das Update des DOM aus, und dann über 10Y für das Darstellen auf dem Bildschirm.

D.h. durch eine Optimierung beim Erzeugen des HTML sparst Du nicht viel. Der Pferdefuß liegt im Rendering. Das kannst Du nur dadurch beschleunigen, dass möglichst wenige dynamiche Komponenten im Rendering liegen. Angeblich soll table-layout: fixed helfen - bei mir hat es das Rendering allerdings um 50% langsamer gemacht. Keine Ahnung wieso.

Das Aufbauen des HTML geht auf 3 Arten.

1. langsam: eine html Variable als String und jede Zelle daran anhängen
2. schneller: eine html Variable als String, jede Row erstmal in einem eigenen String aufbauen und den, wenn die Row beisammen ist, an die html Variable anhängen
3. am schnellsten: eine html Variable als Array mit fester Größe. Du weißt, dass Du N Zeilen haben wirst. Initialisiere html = Array(N). Jede Row i als String rendern und an html[i] zuweisen, am Ende dann innerHTML = html.join()

Der Punkt ist: einen langen String zu verlängern erfordert, ihn zu kopieren. Ein Array zu verlängern erfordert, die Tabelle mit den Objektreferenzen darin zu kopieren (und ggf. die Referenzzähler an den Strings zu manipulieren). Ein festes Array als Zwischenpuffer verhindert beides, und Array.prototype.join kann, bevor es loslegt, erstmal die benötigte Länge für den Zielstring berechnen und den Speicher bereitstellen.

Die gleiche Überlegung kannst Du für die Row-Aufbereitung anstellen und auch da ein festes Array verwenden. Je nach HTML Menge der Rows hilft das mehr oder weniger

Man könnte überlegen, statt einem HTML String ein DocumentFragment aufzubauen. Aber: das ist zum einen inkompatibel zum IE (d.h. du müsstest dafür einen Fallback programmieren oder läufst dort nicht), zum zweiten ist es in meinem Test nicht schneller gewesen (die Übertragung ins DOM ging schneller, aber der Gewinn wurde vom Aufbau des DocumentFragment mehr als aufgefressen) und zum dritten ist der Zeitfresser immer noch das Rendering im Browser, nicht der Update des DOM.

Abgesehen davon hat der Edge-Browser die innerHTML Eigenschaft vor Version 14 nicht unterstützt, aber das sollte heutzutage noch irrelevanter sein als der IE.

Rolf