Wie schnell wird ein Wert in localStorage mit Javascript nachgeschlagen?
Hat jemand Links zu Leistungstests, die angeben, ob es sich lohnt, die Daten in einem JavaScript-Objekt zwischenzuspeichern? Oder cachet der Browser ohnehin schon Werte, auf die von localStorage zugegriffen wird?
Ich interessiere mich besonders fĂĽr Firefox- und Chrome-Implementierungen von localStorage.
Lukas Liese
Habe gerade einen kleinen Benchmark gemacht. Was ich vorhabe, ist, ziemlich oft einige Daten von localStorage abzurufen, und ich fragte mich, ob es blockiert wird. Obwohl localStorage.getItem ein synchronisierter Vorgang ist, mag es beängstigend klingen, aber ist es das?
1. Test zum Aufrufen von 1 Million Mal localStorage, um ein Element zu erhalten, das existiert.
2. Test zum Aufrufen von 1 Million Mal localStorage, um ein Element zu erhalten, das NICHT existiert.
Ergebnisse:
“Element gefunden: 0,0007991071428571318 ms pro Anruf”
“Element nicht gefunden: 0,0006365004639793477 ms pro Anruf”
Kurz gesagt – einfach benutzen. Es dauert keine Zeit. 0,0007 von 1 Millisekunde.
let results = [];
let sum = 0;
localStorage.setItem('foo', 'foo bar baz foo bar baz foo bar baz foo');
for (let i = 0; i < 1000000; i++) {
let a = performance.now();
localStorage.getItem('foo');
let result = performance.now() - a;
sum += result;
results.push(result);
}
console.log(`Item found: ${sum / results.length}ms per call`);
results = [];
sum = 0;
for (let i = 0; i < 1000000; i++) {
let a = performance.now();
localStorage.getItem('bar');
let result = performance.now() - a;
sum += result;
results.push(result);
}
console.log(`Item not found: ${sum / results.length}ms per call`);
Sie brauchen einen Bezugspunkt, wie sieht es im Vergleich zum Variablenzugriff aus?
–Kugel
14. März 2018 um 6:37 Uhr
@Kugel Dies wurde nicht zum Vergleichen getan, sondern um zu überprüfen, ob der lokale Hostspeicher schnell genug arbeitet, um keine oder zumindest keine Auswirkungen auf die Gesamtleistung zu haben. Ich frage mich, wie der Test geschrieben werden sollte, um einen echten Vergleich der Dinge zu haben, die Sie vergleichen möchten, und dies liegt mit Sicherheit außerhalb des Bereichs dieser Frage. Wenn Aktionen im Bereich von 0,0007 ms stattfinden, ist selbst dieser Test wahrscheinlich nicht genau genug und deckt nicht ab, wie die CPU und die JS-Engine selbst funktionieren. Mein Interesse war zu überprüfen, ob localhost im Allgemeinen “schnell” ist.
– Lukas Lies
14. März 2018 um 12:52 Uhr
Haben Sie dies mit groĂźen Objekten anstelle einer einfachen Zeichenfolge getestet?
– Sergiu
17. Juni 2018 um 7:54 Uhr
@Sergiu 1. Localstorage speichert nur Strings, keine Objekte. 2. Je nach Browser gibt es Beschränkungen, wie viele Daten gespeichert werden können, und diese Beschränkungen sind nicht groß, z. B. 5 MB. Ich weiß nicht, was für dich “groß” ist.
– Lukas Lies
17. Juni 2018 um 12:11 Uhr
Eigentlich habe ich gefragt, ob es einen Leistungsunterschied gibt, wenn der Wert eine große Zeichenfolge anstelle von nur wenigen Zeichen enthält?
– Sergiu
19. Juni 2018 um 6:46 Uhr
FĂĽr das, was es wert ist, hier ist ein jsperf-Test.
Die Benchmark-Nutzung von localStorage ist deutlich langsamer als Zugriff von a reguläre Objekteigenschaften in FF7 und IE9. Natürlich ist dies nur ein Mikro-Benchmark, und spiegelt nicht unbedingt die reale Nutzung oder Leistung wider…
Beispiel aus meinem FF 7-Lauf gezogen, um zu zeigen, was “deutlich langsamer” in Ops/Sekunde bedeutet:
native local-storage notes
small set 374,397 13,657 10 distinct items
large set 2,256 68 100 distinct items
read-bias 10,266 342 1 write, 10 reads, 10 distinct items
Außerdem gibt es Einschränkungen hinsichtlich dessen, was in localStorage abgelegt werden kann. YMMV.
Aber reguläre Objekte werden nicht beibehalten. Dies ist wie der Vergleich des Variablenzugriffs mit dem SQL-Speicher. Sie haben unterschiedliche Zwecke und ersteres ist immer viel schneller als letzteres.
– Kammerherr
2. Juli 2019 um 6:39 Uhr
@cchamberlain Es ist immer noch wichtig zu wissen, z. B. wenn Sie überlegen, ob häufig verwendete Daten innerhalb der Seite zwischengespeichert werden sollen (und möglicherweise die Konsistenz über mehrere Registerkarten / Fenster hinweg verwaltet werden muss) oder sie immer abgerufen werden sollen localStorage. Ich stehe derzeit vor dieser Entscheidung für ein OAuth-Aktualisierungstoken und einen anderen dauerhaften Anwendungsstatus. Zufälligerweise hat ein anderer Lukas dies bereits unter Ihrer Antwort besprochen.
– Lukas
13. Oktober 2020 um 16:07 Uhr
Kammerherr
Ă„pfel zu Ă„pfeln
Vergleichen hat nicht viel Wert localStorage Zur Objektspeicherung haben die beiden in JavaScript unterschiedliche Zwecke. Es ist wahrscheinlich, dass Sie nur berĂĽhren mĂĽssen localStorage ein paar Mal in Ihrer App und der Rest der Arbeit wird im Speicher erledigt.
Lokale Speicherung vs. Cookies
Ein besserer Vergleich dagegen localStorage wäre das seines klassischen Gegenstücks, document.cookie. Beide localStorage und document.cookieDer Hauptzweck von ist es, einen Wert über Browseraktualisierungen hinweg beizubehalten.
Ich habe ein Beispiel dazu zusammengestellt codsandbox.io
localStorage ist zwei Größenordnungen schneller als document.cookie.
Object Speicherung ist eine Größenordnung schneller als localStorage (irrelevant, aber als Referenz hinzugefügt).
localStorage ist bei weitem der schnellste Mechanismus, um Werte ĂĽber eine Browseraktualisierung hinweg beizubehalten.
Beachten Sie, dass ich Cookie-Regex-Getter vorkompiliert habe, um Cookies so schnell wie möglich zu erstellen, und die Browserleistungs-API für genaue Messungen verwendet habe. Alle Tests führen einen Satz eines eindeutigen Schlüssels aus, gefolgt von einem Abruf desselben Schlüssels.
Das ist nicht der Punkt und beantwortet die Frage nicht. Vielleicht möchte ich entscheiden, ob ich einen Cache meiner gemeinsam genutzten Variablen regelmäßig speichern (und regelmäßig aktualisieren) oder einfach in localStorage belassen und regelmäßig überprüfen soll? Das ist der Punkt der Frage, und das beantwortet sie nicht.
– DJ Clayworth
28. Oktober 2019 um 15:57 Uhr
Definiere “normale Speicherung”. Das Einfügen eines Werts in eine globale Variable hat nicht viel mit zu tun localStorage aus Sicht der Anwendungsfälle. Lesen von Daten aus localStorage nimmt es von der Festplatte in den Speicher, also vergleichen Sie eine Sache, Azu A + B. Einer ist für die temporäre Verwendung im Arbeitsspeicher und der andere für die Persistenz auf der Festplatte. Sie kaufen RAM und Festplatten nicht im selben Geschäft. Diese Frage wirft ein schlechtes Licht auf localStorage und es vergleicht es nicht einmal mit seinem klassischen Gegenstück, Keksen.
– Kammerherr
28. Oktober 2019 um 23:04 Uhr
Wenn Sie nach Möglichkeiten suchen, Objekte zu speichern, und versuchen, dies mit lokalem Speicher zu tun, wette ich, dass die meiste Zeit verbraucht wird, um Objekte in Zeichenfolgen und zurück zu verschieben. Der beliebteste Weg wäre z. B. JSON stringify, was eine etwas langsame Operation ist.
– Lukas Lies
23. Dezember 2019 um 7:53 Uhr
@LukasLiesis Es ist wahr, dass JSON stringify sehr häufig zum Serialisieren in Zeichenfolgen zum Einfügen in den lokalen Speicher verwendet wird, aber das sollte nicht in einem Benchmark des lokalen Speichers selbst enthalten sein. Was mir an vielen Antworten auf diese Frage nicht gefällt, ist, dass sie den localStorage-Zugriff mit dem regulären Variablenzugriff vergleichen und die beiden sehr wenig gemeinsam haben. Um die Frage zu beantworten, scheint localStorage Lesevorgänge nicht zwischenzuspeichern, aber es als “sehr langsam” zu bezeichnen, ist eine falsche Bezeichnung. Es ist viel schneller als seine dauerhaften Alternativen (Cookies).
– Kammerherr
12. März 2020 um 20:27 Uhr
Ich schätze die Bemühungen der vorherigen Antworten, fand aber, dass die Benchmarks fehlen. Hier ist ein besserer Mikro-Benchmark, beachten Sie, es ist immer noch ein Mikro-Benchmark. Ziehen Sie es immer vor, echte Leistungsengpässe zu messen, anstatt eine vorzeitige Leistungsoptimierung vorzunehmen.
Benchmarks dienen zum Lesen und Schreiben eines einzelnen Werts, einer Liste mit hundert Objekten und einer Liste mit zehntausend Objekten von und zu localStorage.
TL;DR:
single read: 0.0004ms, write: 0.0114ms
small list read: 0.0325ms, write: 0.0498ms
large list read: 3.1787ms, write: 3.3190ms
Läuft auf einem 3,1 GHz Quad-Core Intel Core i7. Chrom 79.
read local storage - single x 2,439,715 ops/sec ±0.91% (62 runs sampled)
read local storage - small x 30,742 ops/sec ±0.78% (62 runs sampled)
read local storage - large x 315 ops/sec ±1.30% (60 runs sampled)
write local storage - single x 88,032 ops/sec ±4.25% (33 runs sampled)
write local storage - small x 20,079 ops/sec ±1.89% (59 runs sampled)
write local storage - large x 301 ops/sec ±1.09% (60 runs sampled)
Test: read local storage - single
mean: 0.0004098839352502669ms
margin of error: ±0.000003731514453196282ms
devation: ±0.00001499080315635531ms
Test: read local storage - small
mean: 0.03252840093744983ms
margin of error: ±0.0002551322114660716ms
devation: ±0.001024955633672395ms
Test: read local storage - large
mean: 3.1786666666666674ms
margin of error: ±0.041479799689699ms
devation: ±0.16392915653288143ms
Test: write local storage - single
mean: 0.011359496605398242ms
margin of error: ±0.00048286808926899016ms
devation: ±0.0014152377493978731ms
Test: write local storage - small
mean: 0.04980309857651518ms
margin of error: ±0.0009408982120607311ms
devation: ±0.0036873348473201325ms
Test: write local storage - large
mean: 3.31899154589372ms
margin of error: ±0.03605551145015122ms
devation: ±0.14249224018921072ms
Hier ist ein Ausschnitt, um es selbst auszuführen, wenn Sie möchten.