JavaScript geïnterpreteerd of gecompileerd?

Computers kunnen de code die u in JavaScript schrijft (of wat voor taal dan ook) niet uitvoeren. Computers kunnen alleen machinecode uitvoeren. De machinecode die een bepaalde computer kan uitvoeren, is gedefinieerd in de processor die deze opdrachten uitvoert en kan voor verschillende processors verschillen.

Het was duidelijk dat het schrijven van machinecode moeilijk was voor mensen (is 125 een add-opdracht of is het 126 of misschien 27). Om dat probleem te omzeilen zijn zogenaamde assemblagetalen gemaakt. Deze talen gebruikten meer voor de hand liggende namen voor de commando's (zoals TOEVOEGEN om toe te voegen) en dus verdwenen de noodzaak om de exacte machinecodes te onthouden. Assemblagetalen hebben nog steeds een één-op-één relatie met de specifieke processor en machinecode waarnaar de computer die opdrachten converteert.

Montagetalen moeten worden gecompileerd of geïnterpreteerd

Al heel vroeg werd duidelijk dat gemakkelijker te schrijven talen nodig waren en dat de computer zelf kon worden gebruikt om deze te vertalen in de machinecode-instructies die de computer daadwerkelijk kan begrijpen. Er waren twee benaderingen die met deze vertaling konden worden gevolgd en beide alternatieven werden gekozen (de ene of de andere zal worden gebruikt, afhankelijk van de taal die wordt gebruikt en waar deze wordt uitgevoerd).

Een gecompileerde taal is een taal waarin u, zodra het programma is geschreven, de code invoert via een programma dat een compiler wordt genoemd en dat een machinecodeversie van het programma produceert. Wanneer u het programma wilt uitvoeren, belt u gewoon de machinecodeversie. Als u wijzigingen aanbrengt in het programma, moet u het opnieuw compileren voordat u de gewijzigde code kunt testen.

Een geïnterpreteerde taal is een taal waarin de instructies worden geconverteerd van wat u hebt geschreven in machinecode terwijl het programma wordt uitgevoerd. Een geïnterpreteerde taal krijgt in principe een instructie van de programmabron, converteert deze naar machinecode, voert die machinecode uit en grijpt vervolgens de volgende instructie van de bron om het proces te herhalen.

Twee varianten op compileren en tolken

Eén variant gebruikt een tweetrapsproces. Met deze variant wordt de bron van uw programma niet direct in de machinecode gecompileerd, maar in plaats daarvan omgezet in een assemblageachtige taal die nog steeds onafhankelijk is van de specifieke processor. Wanneer u de code wilt uitvoeren, verwerkt het die gecompileerde code vervolgens via een voor de processor specifieke tolk om de machinecode te krijgen die geschikt is voor die processor. Deze aanpak heeft veel van de voordelen van compileren met behoud van processoronafhankelijkheid, omdat dezelfde gecompileerde code door veel verschillende processors kan worden geïnterpreteerd. Java is een taal die deze variant vaak gebruikt.

De andere variant wordt een Just in Time-compiler (of JIT) genoemd. Met deze aanpak voert u de compiler niet meer uit nadat u uw code hebt geschreven. In plaats daarvan gebeurt dat automatisch wanneer u de code uitvoert. Met een Just in Time-compiler wordt de code niet statement per statement geïnterpreteerd, het wordt in één keer gecompileerd telkens wanneer het wordt opgeroepen om te worden uitgevoerd en vervolgens wordt de gecompileerde versie die zojuist is gemaakt, uitgevoerd. Deze benadering zorgt ervoor dat het lijkt alsof de code wordt geïnterpreteerd, behalve dat in plaats van fouten alleen worden gevonden wanneer de instructie met de fout wordt bereikt, fouten die door de compiler worden gedetecteerd, ertoe leiden dat geen van de code wordt uitgevoerd in plaats van alle code tot dat moment wordt uitgevoerd. PHP is een voorbeeld van een taal die meestal just in time-compilatie gebruikt.

Is JavaScript gecompileerd of geïnterpreteerd?

Dus nu weten we wat geïnterpreteerde code en gecompileerde code betekent, de vraag die we vervolgens moeten beantwoorden is wat dit allemaal te maken heeft met JavaScript? Afhankelijk van waar u uw JavaScript uitvoert, kan de code worden gecompileerd of geïnterpreteerd of een van de twee andere genoemde varianten gebruiken. Meestal voert u uw JavaScript uit in een webbrowser en daar wordt het JavaScript meestal geïnterpreteerd.

Geïnterpreteerde talen zijn meestal langzamer dan gecompileerde talen. Daar zijn twee redenen voor. Ten eerste moet de te interpreteren code daadwerkelijk worden geïnterpreteerd voordat deze kan worden uitgevoerd en ten tweede moet dit elke keer gebeuren dat de instructie moet worden uitgevoerd (niet alleen elke keer dat u JavaScript uitvoert, maar als het in een lus staat, dan moet elke keer rond de lus worden gedaan). Dit betekent dat code die in JavaScript is geschreven langzamer wordt uitgevoerd dan code die in veel andere talen is geschreven.

Hoe helpt dit ons te helpen waar JavaScript de enige taal is die beschikbaar is voor alle webbrowsers? De JavaScript-interpreter zelf die in de webbrowser is ingebouwd, is niet in JavaScript geschreven. In plaats daarvan is het geschreven in een andere taal die vervolgens werd gecompileerd. Dit betekent dat u uw JavaScript sneller kunt laten werken als u kunt profiteren van alle opdrachten die JavaScript biedt waarmee u de taak naar de JavaScript-engine zelf kunt verplaatsen.

Voorbeelden om JavaScript sneller te laten werken

Een voorbeeld hiervan is dat sommige maar niet alle browsers een methode document.getElementsByClassName () in de JavaScript-engine hebben geïmplementeerd, terwijl anderen dat nog moeten doen. Wanneer we deze specifieke functionaliteit nodig hebben, kunnen we de code sneller laten werken in die browsers waar de JavaScript-engine deze biedt door middel van functie-detectie om te zien of de methode al bestaat en alleen onze eigen versie van die code in JavaScript maken als de JavaScript-engine niet ' t bieden het voor ons. Waar de JavaScript-engine die functionaliteit biedt, zou deze sneller moeten werken als we die gebruiken in plaats van onze eigen versie die in JavaScript is geschreven. Hetzelfde geldt voor alle verwerkingen die de JavaScript-engine voor ons beschikbaar stelt om rechtstreeks te bellen.

Er zullen ook gevallen zijn waarin JavaScript meerdere manieren biedt om hetzelfde verzoek in te dienen. In die gevallen kan een van de manieren om toegang te krijgen tot de informatie specifieker zijn dan de andere. Bijvoorbeeld document.getElementsByTagName ('table') [0] .tBodies en document.getElementsByTagName ('table') [0] .getElementsByTagName ('tbody') halen beide dezelfde nodelist op van de tbody-tags in de eerste tabel op het web pagina maar de eerste hiervan is een specifiek commando voor het ophalen van de tbody-tags, terwijl de tweede aangeeft dat we tbody-tags in een parameter ophalen en andere waarden kunnen worden vervangen om andere tags op te halen. In de meeste browsers werkt de kortere en meer specifieke variant van de code sneller (in sommige gevallen veel sneller) dan de tweede variant en daarom is het logisch om de kortere en meer specifieke versie te gebruiken. Het maakt de code ook gemakkelijker te lezen en te onderhouden.

Nu is in veel van deze gevallen het werkelijke verschil in verwerkingstijd erg klein en het is alleen wanneer u veel van dergelijke codekeuzes bij elkaar optelt, dat u een merkbaar verschil krijgt in de tijd die uw code nodig heeft om te worden uitgevoerd. Het is echter vrij zeldzaam dat het wijzigen van uw code om het sneller te laten werken, de code aanzienlijk langer of moeilijker maakt om te onderhouden, en vaak zal het omgekeerde waar zijn. Er is ook het extra voordeel dat toekomstige versies van JavaScript-engines kunnen worden gemaakt die de meer specifieke variant nog verder versnellen, zodat het gebruik van de specifieke variant kan betekenen dat uw code in de toekomst sneller wordt uitgevoerd zonder dat u iets hoeft te wijzigen.