Betydning af fortolket eller kompileret i JavaScript

Computere kan faktisk ikke køre den kode, du skriver i JavaScript (eller ethvert andet sprog for den sags skyld). Computere kan kun køre maskinkode. Maskinkoden, som en bestemt computer kan køre, defineres i processoren, der vil køre disse kommandoer, og kan være forskellige for forskellige processorer.

Naturligvis, skrivemaskinkode var svært for folk at gøre (er 125 en tilføjelseskommando eller er det 126 eller måske 27). For at omgå dette problem blev der oprettet det, der er kendt som samlingssprog. Disse sprog brugte mere åbenlyse navne på kommandoerne (f.eks. ADD til at tilføje) og fjernede således behovet for at huske de nøjagtige maskinkoder. Samlingssprog har stadig et forhold til én til den bestemte processor og maskinkode, som computeren konverterer disse kommandoer til.

Meget tidligt blev det klar over, at det var lettere at skrive Sprog var nødvendige, og at selve computeren kunne bruges til at oversætte dem til maskinkodeinstruktioner, som computeren faktisk kan forstå. Der var to tilgange, der kunne tages med denne oversættelse, og begge alternativer blev valgt (enten det ene eller det andet bruges afhængigt af det sprog, der bruges, og hvor det køres).

Et sammensat sprog er et, hvor når programmet først er skrevet, du indtaster koden gennem et program kaldet a compiler og der producerer en maskinkodeversion af programmet. Når du vil køre programmet, skal du bare kalde maskinkodeversionen. Hvis du foretager ændringer i programmet, skal du igen kompilere det, før du kan teste den ændrede kode.

Et tolket sprog er et, hvor instruktionerne konverteres fra det, du har skrevet til maskinkode, mens programmet køres. Et tolket sprog får dybest set en instruktion fra programkilden, konverterer det til maskine kode, kører maskinkoden og griber derefter den næste instruktion fra kilden til gentagelse af behandle.

En variant bruger en totrinsproces. Med denne variant kompileres dit program ikke direkte i maskinkoden, men i stedet konverteres til et samlingslignende sprog, der stadig er uafhængigt af det pågældende processor. Når du vil køre koden, behandles den derefter den kompilerede kode gennem en tolk, der er specifik for processoren, så maskinkoden passer til den processor. Denne tilgang har mange af fordelene ved at udarbejde, samtidig med at processoren er uafhængig, da den samme kompilerede kode kan fortolkes af mange forskellige processorer. Java er et sprog, der ofte bruger denne variant.

Den anden variant kaldes en Just in Time-kompilator (eller JIT). Med denne tilgang kører du faktisk ikke kompilatoren, når du har skrevet din kode. I stedet for sker det automatisk, når du kører koden. Ved hjælp af en Just in Time-kompilator fortolkes koden ikke sætning efter sætning, den kompileres alt sammen gå hver gang det kaldes til at blive kørt, og så er den kompilerede version, den netop oprettede, hvad der får løb. Denne fremgangsmåde får det til at se meget ud som om koden fortolkes bortset fra at i stedet for kun at blive fundet fejl, når udsagnet med Der opnås en fejl, eventuelle fejl, der detekteres af kompilatoren, resulterer i, at ingen af ​​koden køres i stedet for at hele koden op til dette punkt er løb. PHP er et eksempel på et sprog, der normalt kun bruges i tidsindsamling.

Så nu ved vi, hvad tolket kode og kompileret kode betyder. Spørgsmålet, som vi næste skal svare på, er, hvad har alt dette med JavaScript at gøre? Afhængigt af nøjagtigt, hvor du kører din JavaScript, kan koden sammenstilles eller fortolkes eller bruge en af ​​de to andre nævnte varianter. Det meste af tiden er dukører din JavaScript i en webbrowser og der tolkes JavaScript normalt.

Tolkede sprog er normalt langsommere end kompilerede sprog. Der er to grunde til dette. For det første skal koden, der skal fortolkes, faktisk fortolkes, før den kan køres, og for det andet skal ske hver gang udsagnet skal køres (ikke kun hver gang du kører JavaScript, men hvis det er i -en loop så skal det gøres hver gang rundt løkken). Dette betyder, at kode, der er skrevet i JavaScript, kører langsommere end kode, der er skrevet på mange andre sprog.

Hvordan hjælper det at vide dette, hvor JavaScript er det eneste sprog, der er tilgængeligt for os at køre på tværs af alle browsere? Selve JavaScript-tolken, der er indbygget i webbrowseren, er ikke skrevet i JavaScript. I stedet er det skrevet på et andet sprog, der derefter blev samlet. Hvad dette betyder er, at du kan få dit JavaScript til at køre hurtigere, hvis du kan drage fordel af de kommandoer, som JavaScript leverer, som giver dig mulighed for at downloade opgaven til selve JavaScript-motoren.

Et eksempel på dette er, at nogle, men ikke alle browsere, har implementeret en document.getElementsByClassName () -metode i JavaScript-motoren, mens andre endnu ikke har gjort det. Når vi har brug for netop denne funktionalitet, kan vi slå ud, at koden kører hurtigere i de browsere, hvor JavaScript-motoren leverer den ved hjælp af funktionen sensing for at se, om metoden allerede findes, og kun oprette vores egen version af den kode i JavaScript, når JavaScript-motoren ikke indeholder den til os. Hvor JavaScript-motoren leverer denne funktionalitet, skal den køre hurtigere, hvis vi bruger den snarere end at køre vores egen version skrevet i JavaScript. Det samme gælder for enhver behandling, som JavaScript-motoren stiller til rådighed for os at kunne ringe direkte til.

Der vil også være tilfælde, hvor JavaScript giver flere måder at fremsætte den samme anmodning på. I disse tilfælde kan en af ​​måderne til adgang til informationen være mere specifik end den anden. F.eks. Document.getElementsByTagName ('tabel') [0] .tBodies og document.getElementsByTagName ('tabel') [0] .getElementsByTagName ('tbody') begge hente den samme nodelist for tbody-tags i den første tabel på websiden, men den første af disse er en bestemt kommando til hentning tbody-tags, hvor det andet identificerer, at vi henter tbody-tags i en parameter, og andre værdier kan erstattes for at hente andre tags. I de fleste browsere kører den kortere og mere specifikke variant af koden hurtigere (i nogle tilfælde meget hurtigere) end den anden variant, og det giver derfor mening at bruge den kortere og mere specifikke version. Det gør også koden lettere at læse og vedligeholde.

I mange af disse tilfælde vil den faktiske forskel i behandlingstid være meget lille, og det vil kun være hvornår tilføjer du mange sådanne kodevalg sammen, som du vil få nogen mærkbar forskel i den tid, din kode tager løb. Det er dog ganske sjældent, at hvis du ændrer din kode for at få den til at køre hurtigere, gør koden markant længere eller sværere at vedligeholde, og ofte vil det omvendte være sandt. Der er også den ekstra fordel, at der muligvis oprettes fremtidige versioner af JavaScript-motorer, der også fremskynder den mere specifikke variant yderligere, så at brug af den specifikke variant kan betyde, at din kode kører hurtigere i fremtiden, uden at du behøver at ændre noget.