Doorgaan naar hoofdinhoud

Prestaties van Immer

[Onofficiële Beta-vertaling]

Deze pagina is vertaald door PageTurner AI (beta). Niet officieel goedgekeurd door het project. Een fout gevonden? Probleem melden →

egghead.io lesson 5: Leveraging Immer's structural sharing in React
egghead.io lesson 7: Immer will try to re-cycle data if there was no semantic change

Hier is een eenvoudige benchmark over de prestaties van Immer. Deze test neemt 50.000 todo-items en werkt 5.000 ervan bij. Freeze geeft aan dat de statenboom na het produceren is bevroren. Dit is een best practice voor ontwikkeling, omdat het voorkomt dat ontwikkelaars per ongeluk de statenboom wijzigen.

Iets wat niet in de bovenstaande cijfers naar voren komt, is dat Immer in de praktijk soms aanzienlijk sneller is dan een handgeschreven reducer. Dit komt doordat Immer "no-op" statenwijzigingen detecteert en de originele staat teruggeeft als er niets daadwerkelijk is veranderd, wat bijvoorbeeld veel her-renderingen kan voorkomen. Er zijn gevallen bekend waarin het simpelweg toepassen van Immer kritieke prestatieproblemen oploste.

Deze tests zijn uitgevoerd op Node 10.16.3. Gebruik yarn test:perf om ze lokaal te reproduceren.

prestatiegrafiek

Belangrijkste observatie:

  • Immer met proxies is grofweg twee tot drie keer langzamer dan een handgeschreven reducer (bovenstaande testcase is het slechtste scenario, zie yarn test:perf voor meer tests). Dit is in de praktijk verwaarloosbaar.

  • Immer is ongeveer even snel als ImmutableJS. Echter, immutableJS + toJS maakt de kosten duidelijk die later vaak betaald moeten worden: het terugconverteren van immutableJS-objecten naar gewone objecten om ze door te kunnen geven aan componenten, over het netwerk, etc. (Daarnaast zijn er initiële kosten voor het converteren van data ontvangen van bijvoorbeeld de server naar immutable JS)

  • Het genereren van patches vertraagt Immer niet significant

  • De ES5-fallbackimplementatie is ongeveer twee keer zo langzaam als de proxy-implementatie, in sommige gevallen slechter.

Prestatie tips​

Schakel de Array Methods Plugin in​

Voor applicaties met aanzienlijke array-iteratie binnen producers, schakel de Array Methods Plugin in:

import {enableArrayMethods} from "immer"
enableArrayMethods()

Deze plugin optimaliseert arraybewerkingen zoals filter, find, some, every en slice door het aanmaken van proxies voor elk element tijdens iteratie te vermijden. Zonder de plugin creëert het itereren van een array met 1000 elementen 1000+ proxies. Met de plugin ontvangen callbacks basiswaarden, en worden proxies alleen aangemaakt voor elementen die je daadwerkelijk wijzigt.

Gebruik loose iteration voor betere prestaties​

Standaard gebruikt Immer loose iteration die alleen enumerable string-eigenschappen verwerkt. Dit is sneller dan strict iteration die symbolen en niet-enumerable eigenschappen omvat. Voor de meeste gebruiksscenario's is de standaardinstelling optimaal:

import {setUseStrictIteration} from "immer"

// Default: false (loose iteration for better performance)
setUseStrictIteration(false)

Schakel strict iteration alleen in als je specifiek symbolen of niet-enumerable eigenschappen moet volgen.

Data vooraf bevriezen​

Bij het toevoegen van een grote dataset aan de statenboom in een Immer-producer (bijvoorbeeld data ontvangen van een JSON-eindpunt), is het de moeite waard om eerst freeze(json) aan te roepen op de root van de toegevoegde data. Dit bevriest de data oppervlakkig. Hierdoor kan Immer de nieuwe data sneller aan de boom toevoegen, omdat het niet nodig is om de nieuwe data recursief te scannen en te bevriezen.

Je kunt altijd uitschakelen​

Bedenk dat Immer overal opt-in is, dus het is prima om handmatig superkritieke reducers te schrijven en Immer voor alle normale te gebruiken. Zelfs vanuit een producer kun je Immer voor bepaalde delen van je logica uitschakelen door utilities zoals original of current te gebruiken en sommige bewerkingen op gewone JavaScript-objecten uit te voeren.

Voor dure zoekopdrachten: lees van de originele staat, niet de conceptversie​

Immer zal alles wat je in een conceptversie leest ook recursief in een conceptversie veranderen. Als je dure bijwerkingvrije operaties hebt op een conceptversie die veel lezen vereist, zoals het vinden van een index met find(Index) in een zeer grote array, kun je dit versnellen door eerst de zoekopdracht uit te voeren en pas de produce-functie aan te roepen als je de index weet. Hiermee voorkom je dat Immer alles wat werd doorzocht in een conceptversie verandert. Of voer alternatief de zoekopdracht uit op de originele waarde van een conceptversie door original(someDraft) te gebruiken, wat op hetzelfde neerkomt.

Trek produce zo ver mogelijk omhoog​

Probeer altijd produce 'omhoog' te trekken. Bijvoorbeeld: for (let x of y) produce(base, d => d.push(x)) is exponentieel langzamer dan produce(base, d => { for (let x of y) d.push(x)})