Een nieuwe optimalisatie in Chrome verbetert de manier waarop IndexedDB-gegevens op schijf worden opgeslagen. Deze verbetering richt zich op hoe grote waarden worden beheerd binnen het opslagsysteem van Chrome, met name door compressie toe te passen op bepaalde bestanden die op schijf zijn opgeslagen. Het artikel vat de belangrijkste punten van deze update samen.
Opslagmechanisme van Chrome vóór versie 129
Chrome gebruikt LevelDB om IndexedDB-gegevens op schijf op te slaan. LevelDB is een snelle bibliotheek voor het opslaan van sleutel-waardegegevens, maar ondervindt problemen wanneer individuele waarden de grootte van een databasepagina overschrijden. Om dit probleem aan te pakken, slaat Chrome sinds 2017 waarden groter dan één pagina als gewone bestanden op de schijf op, naast het databasebestand.
Opslag van versie 129
Compressie van grote waarden
In tegenstelling tot de inhoud die rechtstreeks in de LevelDB-database wordt opgeslagen, die wordt gecomprimeerd voordat deze naar schijf wordt geschreven en gedecomprimeerd nadat deze is gelezen, werden de grote bestanden die als gewone bestanden werden opgeslagen, niet gecomprimeerd. Met de nieuwe update comprimeert Chrome deze grote bestanden nu met behulp van de Snappy realtime compressiebibliotheek, wat resulteert in aanzienlijke ruimtebesparing. Dit is vooral effectief voor gestructureerde data, zoals grote arrays met JavaScript-waarden, XML of JSON. Het is niet effectief voor mediabestanden die groot zijn maar al gecomprimeerd, of, minder gebruikelijk, als de site zelf al in- en uitpakt.
Impact op opslagefficiëntie
Als de compressie de bestandsgrootte verkleint tot onder de grootte van een LevelDB-pagina, worden de gegevens teruggeplaatst in LevelDB. Deze wijziging bespaart niet alleen ruimte, maar vermindert ook het aantal I/O-bewerkingen op de schijf, wat de algehele prestaties verbetert.
Snappy compressie-algoritme
Het Chrome-team koos Snappy voor compressie omdat het optimaliseert op snelheid in plaats van maximale compressie. Het is snel genoeg om geen meetbare prestatievermindering te veroorzaken tijdens compressie of decompressie.
Prestatieverbeteringen
De compressie en decompressie worden afgehandeld binnen het renderproces, onderdeel van Chrome's multiprocessarchitectuur. Dit verkleint de berichten die naar het browserproces worden verzonden, wat leidt tot verdere prestatieverbeteringen. Synthetische benchmarks hebben aangetoond dat deze update sommige bewerkingen twee tot drie keer sneller kan maken dan voorheen dankzij verminderde IPC (Inter-Process Communication) en schijf-I/O. In de praktijk, volgens metingen van het Chrome-team, worden gestructureerde dataladingen van 1 MB in ongeveer een kwart van de tijd van schijf naar pagina verzonden (met een hoge variabiliteit afhankelijk van de hardware van het apparaat en de systeemactiviteit).
Impact op ontwikkelaars en gebruikers
Deze wijzigingen zijn volledig transparant voor zowel ontwikkelaars als gebruikers. Gebruikers kunnen echter wel verbeteringen in prestaties en een lager opslaggebruik opmerken.
- Ruimtebesparing: De compressie wordt alleen toegepast op nieuwe gegevens die na deze update worden opgeslagen. De ruimtebesparing is indirect te zien via web-API's zoals
navigator.storage.estimate()of in de sectie Opslag in Chrome DevTools onder het paneel Toepassingen . - De functie testen: ontwikkelaars kunnen dit gedrag testen in pre-releaseversies van Chrome (vóór 129) door de functie in te schakelen met de vlag:
--enable-features="IndexedDBCompressValuesWithSnappy".
Deze update verbetert de efficiëntie van Chrome bij het beheren van grote IndexedDB-waarden en biedt zowel ruimte- als tijdbesparing zonder dat dit ten koste gaat van de prestaties. Dit betekent een aanzienlijke verbetering in de manier waarop gegevens in de browser worden opgeslagen en geopend. Door deze veranderingen te begrijpen, kunnen ontwikkelaars profiteren van de voortdurende inspanningen om de prestaties en opslagmechanismen van Chrome te optimaliseren, wat zorgt voor een soepelere en efficiëntere gebruikerservaring.
Dankbetuigingen
Dit document is beoordeeld door Evan Stade en Rachel Andrew .