Warum dieses Projekt?

JavaScript verwaltet Objektlebensdauern normalerweise automatisch. Das ist bequem, kann bei großen, lange gehaltenen Datenbeständen aber zusätzlichen Aufwand verursachen. BumpArena bietet einen anderen Weg: Die Anwendung legt Werte in einem binären Speicherbereich ab und bestimmt selbst, wann Einträge freigegeben werden.

Ein zusammenhängendes Regal für viele Datensätze

Bei einer großen Sammlung von Protokolleinträgen können Zeitstempel, Kennnummern und Textdaten nach einem festen Schema gespeichert werden. Statt pro Eintrag ein Objekt anzulegen, liefert die Arena einen Verweis auf dessen Platz im gemeinsamen Speicher.

Kennungen erkennen veraltete Verweise nach einer Freigabe. Für häufiges Lesen gibt es wiederverwendbare Leser, damit nicht für jeden Datensatz erneut eine kleine JavaScript-Ansicht erzeugt werden muss. Die Anwendung bleibt dafür verantwortlich, laufende Zugriffe nicht mit dem Freigeben derselben Daten zu überschneiden.

Wann diese Aufteilung sinnvoll ist

Der Ansatz passt vor allem zu Daten, die längere Zeit im Speicher bleiben oder zwischen Arbeitsthreads gelesen werden sollen. Für einen Datenstrom, der nur einmal ausgewertet und sofort verworfen wird, kann direktes Verarbeiten einfacher und schneller sein.

Es wird nicht die gesamte Speicherverwaltung von JavaScript abgeschafft. Die Bibliothek und der Anwendungscode verwenden weiterhin die Laufzeit. Mehr Kontrolle über das Datenlayout erkauft man sich mit eigener Verantwortung für Format, Zugriff und Lebensdauer.

Was die veröffentlichten Messwerte tatsächlich zeigen

Eine veröffentlichte Benchmark-Momentaufnahme vergleicht eine Standard-Array-Variante mit dem TURBO-Pfad von BumpArena. Sie meldet etwa 8,06 gegenüber 8,27 Millionen eingelesene Zeilen pro Sekunde und rund 12,15 gegenüber 11,74 GB Prozessspeicher.

Gemeldeter Prozessspeicher Veröffentlichte Momentaufnahme · keine aktuelle Mehrfachmessung

Einlese-Benchmark

Standard12,15 GB
BumpArena11,74 GB

Alle Balken verwenden dieselbe lineare Skala von 0 bis 14 GB. Im Bericht angegebener Prozessspeicher (RSS). Die Tabelle enthält keine vollständigen Hardware- und Streuungsangaben; keine Aussage über alle Datenbestände oder die aktuelle Bibliotheksversion.

Das sind in diesem Lauf ungefähr 2,6 % mehr Einlesedurchsatz und 3,4 % weniger gemeldeter Prozessspeicher – kein Nachweis einer allgemeinen mehrfachen Beschleunigung. Die kurze Ergebnistabelle dokumentiert weder eine vollständige Hardwarebeschreibung noch eine Streuung über mehrere Läufe.

Die Zahlen erklären deshalb eher die Fragestellung als eine universelle Rangliste: Lohnt sich ein kontrolliertes Binärlayout für genau diesen Datenbestand? Das muss für die eigene Anwendung einschließlich Einlesen, Aufbewahren und Abfragen gemessen werden.

Veröffentlichte Benchmark-Momentaufnahme auf GitHub (Englisch) →

Quellcode & Dokumentation

Quellcode und die verfügbare Projektdokumentation findest du auf GitHub. Dort stehen auch die Hinweise zum Bauen, zur Nutzung und zur Lizenz.

BumpArena auf GitHub ↗

Weiter entdecken