JavaScript. So erstellen Sie ein blitzschnelles Multithread-Datenraster für Zeilen. Teil: Die Nuancen der Arbeit mit DOM

Demo | GitHub

Abbildung 1. Datenraster mit 1.000.000 Zeilen

Fast Data Grid-Funktionen:

• Unglaublich schnell
• Multithreaded
• Nur ​​523 Zeilen Code
• Keine Abhängigkeiten
• Vanille-JavaScript

Versuchen Sie, 1.000.000 Zeilen zu scrollen und zu durchsuchen – Fast Data Grid.

In diesem Artikel werde ich die Nuancen der Arbeit mit DOM auflisten. Über Multithreading im nächsten Artikel.

Je kleiner das DOM, desto besser. Das Ändern des Inhalts eines DIV ist schneller als das Löschen eines DIV und das Erstellen eines neuen.

Der Browser ist beim Rendern eines großen DOM-Baums langsam. Der Browser rendert überhaupt keine 1.000.000 Zeilen mit einer Höhe von 20 Pixeln – die maximale Höhe eines DIV in Chrome beträgt 15.000.000 Pixel. Je weniger HTML-Elemente, desto besser.

Fast Data Grid fügt dem DOM so viele Zeilen hinzu, wie auf den Bildschirm passen.

const rowsCount = Math.ceil(viewPortHeight / rowHeight);

Listing 1. Zählen, wie viele Zeilen auf den Bildschirm passen

Wenn neue Daten ausgegeben werden müssen, werden die Zeilen-DIVs wiederverwendet. Neue Daten werden in dieselben DIVs geschrieben. Das Ändern des Inhalts eines DIV geht schneller als das Löschen eines DIV und das Erstellen eines neuen.

Beim Scrollen wird die Position der DIV-Zeilen mithilfe von JavaScript berechnet.

Die maximale DIV-Höhe beträgt 15.000.000 Pixel

Damit das Scrollen funktioniert, erstellt Fast Data Grid einen großen DIV. Das Scroll-Ereignis ist an diesen DIV angehängt. Der Scroll-Event-Handler berechnet die Position der Zeilen-DIVs.

Abbildung 2. Großes DIV zum Scrollen

Wenn die Gesamthöhe der Zeilen mehr als 15.000.000 Pixel beträgt, sollten die Zeilen-DIVs schneller scrollen als die großen DIVs. Wenn der große DIV bis zum Ende scrollt -> Die Zeilen-DIVs sollten ebenfalls bis zum Ende scrollen.

Beim Scrollen von DIV-Zeilen muss ein Koeffizient angewendet werden.

const scrollYKoef =
    // if {allRowsHeight} > 15 million -> we have to applay koef on scroll
    // if {allRowsHeight}  {scrollYKoef} = 1
    (allRowsHeight - viewPortHeight) / (scrolHeight - viewPortHeight);


listen(scrollOverlayDiv, 'scroll', /** @param {Event & {target:HTMLDivElement}} evt */ evt => {
    const scrollTop = evt.target.scrollTop * scrollYKoef;
    rowsDiv.style.transform = `translateY(${scrollTop}px)`;
});

Listing 2. Verwendung des Koeffizienten beim Scrollen

Die CSS-Transformationsübersetzung ist schneller als CSS-Top

Beim Scrollen wird die Position per Transform Translate festgelegt. Die CSS-Transformationsübersetzung ist schneller als CSS-Top.

<!-- transform faster-->
<div>

<p><br>
<em>Listing 3. CSS transform translate is faster than CSS top</em></p>
<h2>
  
  
  Read DOM first, then modify DOM. It's bad to read DOM after modification
</h2>

<p>The browser displays frames on the monitor like this:<br>
First, JavaScript is processed, then styles are calculated, then layout, then rendering.</p>

<p><img src="/static/imghwm/default1.png" data-src="https://img.php.cn/upload/article/000/000/000/173464994174788.jpg?x-oss-process=image/resize,p_40" class="lazy" alt="JavaScript. How to Make a Blazingly Fast Multithreaded Data Grid for  Rows. Part : The Nuances of Working with DOM"><em>Figure 3. Standard order of operations when outputting a frame to the monitor</em></p>

<p>If the standard order is not violated, the browser will render the frame as quickly as possible.</p>

<p>At the beginning of the cycle, the DOM parameters are already calculated and correspond to the parameters of the previous frame. For example, box.offsetHeight is already calculated at the beginning of the cycle. But if you change the DOM and then read the DOM -> the browser will have to break the standard order. It will be necessary to calculate the layout again.<br>
</p>

<pre class="brush:php;toolbar:false">box.classList.add('super-big');

// Gets the height of the box in pixels and logs it out:
console.log(box.offsetHeight);

Listing 4. DOM vor dem Lesen von DOM ändern. Schlecht. Führt zu Layout-Überschneidungen.

Eine übermäßige Neuberechnung des Layouts wird als „Layout-Thrashing“ bezeichnet.

Eine visuelle Demonstration, wie das Ändern des DOM vor dem Lesen den Browser verlangsamt:
https://wilsonpage.github.io/fastdom/examples/animation.html

Toller Artikel zum Thema:
Vermeiden Sie große, komplexe Layouts und Layout-Überlastung | Artikel | web.dev.

Eigenwerbung

Ich erstelle den bequemsten Flussdiagramm-Editor DGRM.net.
Es ist auch der bequemste Service für Unternehmen: Excel-Geschäftsprozessdiagramme.

Vergeben Sie Sterne auf GitHub.