Wie viele HTML-Elemente können mit "modernen" Browsern "Griff" auf einmal?

Das ist eine Frage, die nur statistisch versierte Antwort könnte sein, präzise und umfassend.

Warum

Der entsprechenden Gleichung, wobei N die Anzahl der Knoten, bytes_N ist die Gesamtanzahl der bytes benötigt, um Sie in der DOM-Knoten-index-Reihe ist n ∈ [0, N), bytesOverhead ist die Menge des verwendeten Speichers für einen Knoten mit absoluter minimum-Attribut Konfiguration und kein innerHTML, und bytesContent ist die Menge des verwendeten Speichers zu füllen, so eine minimale Knoten.

bytes_N = ∑^N (bytesContent_n + bytesOverhead_n)

Den angeforderten Wert in der Frage ist der maximale Wert von N im worst-case-handheld-Gerät, Betriebssystem, browser -, und Betriebssystem-Bedingungen. Die Lösung für N für jede permutation ist nicht trivial. Die obige Gleichung zeigt drei Abhängigkeiten, von denen jeder könnte drastisch verändern die Antwort.

Abhängigkeiten

1. Die Durchschnittliche Größe eines Knotens, ist abhängig von der durchschnittlichen Anzahl der bytes, die in jedem zu halten, die Inhalte, wie etwa UTF-8 text -, Attribut-Namen und-Werte, oder zwischengespeicherte Informationen bei.
2. Die durchschnittlichen overhead von DOM-Objekt ist abhängig von der HTTP-user-agent für die Verwaltung der DOM-Darstellung von jedem Dokument. W3C Document Object Model FAQ Staaten, "Während alle DOM Implementierungen sollten interoperabel sein, Sie kann stark variieren in code-Größe, Speicherbedarf und Leistung der einzelnen Operationen."
3. Den verfügbaren Arbeitsspeicher zu verwenden, für die DOM-Darstellungen ist abhängig von der browser standardmäßig benutzt werden, (können variieren, je nachdem, welche browser-handheld-Gerät-Anbieter oder Anwender bevorzugen), Benutzer überschreiben der Standard-browser, das Betriebssystem-version, die Speicherkapazität von handheld-Gerät, gemeinsame hintergrund-tasks und anderen Speicher-Verbrauch.

Die Strenge Lösung

Könnte man die tests ausführen, um festzustellen, (1) und (2) für jedes der gemeinsamen http-user-agents verwendet, die auf handheld-Geräten. Die Verteilung des user agents für jede Seite kann erhalten werden, indem die Konfiguration der logging-Mechanismus des web-Servers zu platzieren, der HTTP_USER_AGENT, wenn er nicht da ist standardmäßig aktiviert, und dann die Strippen alle, aber das Feld in der log und das zählen der Instanzen der einzelnen Werte.

Die Anzahl der bytes pro Zeichen würde müssen getestet werden, für die beide Attribute-Werte und UTF-8 text (oder was auch immer der Kodierung), um eine deutliche paar Faktoren für die Berechnung (1).

Den verfügbaren Arbeitsspeicher, würde geprüft werden müssen, auch unter einer Vielzahl von gemeinsamen Bedingungen, das wäre ein großes Forschungsprojekt von selbst.

Dem bestimmten Wert von N gewählt haben würde, zu NULL zu behandeln, die tatsächlichen schlimmsten Fall, so würde man wählte einen bestimmten Prozentsatz von typischen Fällen von content, node-Strukturen, - und Laufzeit-Bedingungen. Zum Beispiel, man kann auch eine Probe von Fällen mit irgendeiner form von randomisierten in-situ - (innerhalb der normalen Umwelt-Bedingungen) studieren und suchen von N erfüllt, dass 95% dieser Fälle.

Vielleicht eine Reihe von Fällen geprüft werden konnte in der oben genannten Möglichkeiten und die Ergebnisse in einer Tabelle angeordnet. Würde damit eine direkte Antwort auf Ihre Frage.

Ich vermute, es würde eine gut ausgebildete, mobile software engineer mit Flair für Mathematik, insbesondere Statistik, fünf Vollzeit-Wochen, um vernünftige Ergebnisse.

Eine Praktische Einschätzung

Könnte man denke, das worst-case-Szenario. Mit ein paar volle Tage der Forschung und ein paar proof-of-concept apps, dieser Vorschlag könnte verfeinert werden. Fehlt die Zeit, das zu tun, hier ist eine gute erste Vermutung.

Erwägen, ein Handy, erlaubt 1 Gbyte für den DOM, da der normale Betriebsbedingungen die Verwendung von 3 GByte von den 4 GByte für die oben genannten Zwecke. Man könnte vermuten, der Durchschnittliche Verbrauch von Speicherplatz für einen Knoten Sie wie folgt vor, um eine ballpark-Figur.

• 2 bytes pro Zeichen 40 Zeichen text pro Knoten
• 2 bytes pro Zeichen für 4 Attribut-Werte von jeweils 10 Zeichen lang
• 1 byte pro Zeichen bei 4 Attribut-Namen von jeweils 4 Zeichen
• 160 bytes für den Knoten C/C++ - overhead in den weniger effizienten Fällen

In diesem Fall N_{worst_case}, im schlimmsten Fall max-Knoten,

= 1,024 X 1,024 X 1,024
  / (2 X 40  +  2 X 4 X 10  +  1 X 4 X 4  +  160)

= 3,195,660 . 190,476.

Ich würde nicht, jedoch, bauen Sie ein Dokument in einem browser mit drei Millionen DOM-Knoten, wenn es sein könnte, überhaupt vermieden. Betrachten beschäftigen, die mehr gängige Praxis unter.

Gängige Praxis

Die beste Lösung ist, um zu bleiben weit unter dem, was N_{worst_case} werden könnte, und reduzieren Sie einfach die Gesamtzahl der Knoten der Grad möglich mit standard-HTTP-design-Techniken.

• Reduzierung der Größe und der Komplexität, die angezeigt auf einer Seite, die auch verbessert die visuelle und konzeptionelle Klarheit.
• Anfrage minimale Mengen von Daten vom server, das zurückstellen von Inhalten, die noch nicht sichtbar windowing-Techniken oder balancing-Antwort-Zeit mit dem Speicherverbrauch gut geplante Wege.
• Verwenden Sie asynchrone Aufrufe, um mit Hilfe der oben Minimalismus.