Betydning av tolket eller kompilert i JavaScript

Datamaskiner kan faktisk ikke bruke koden du skriver i Javascript (eller et hvilket som helst annet språk for den saks skyld). Datamaskiner kan bare kjøre maskinkode. Maskinkoden som en bestemt datamaskin kan kjøre, er definert i prosessoren som skal kjøre disse kommandoene, og kan være forskjellig for forskjellige prosessorer.

Åpenbart, skrivemaskinkode var vanskelig for folk å gjøre (er 125 en kommando eller er det 126 eller kanskje 27). For å komme rundt det problemet ble det som ble kjent som samlingsspråk opprettet. Disse språkene brukte mer åpenbare navn på kommandoene (for eksempel ADD for å legge til) og fjernet dermed behovet for å huske de eksakte maskinkodene. Samlingsspråk har fremdeles et forhold til én til den aktuelle prosessoren og maskinkoden som datamaskinen konverterer disse kommandoene til.

Veldig tidlig ble det klar over at det var lettere å skrive språk var nødvendig og at datamaskinen i seg selv kunne brukes til å oversette disse til maskinens kodeinstruksjoner som datamaskinen faktisk kan forstå. Det var to tilnærminger som kunne tas med denne oversettelsen, og begge alternativene ble valgt (enten det ene eller det andre vil bli brukt avhengig av språket som brukes og hvor det kjøres).

Et sammensatt språk er et der når programmet først er skrevet, du mater koden gjennom et program som heter a kompilatoren og som produserer en maskinkodeversjon av programmet. Når du vil kjøre programmet, kaller du bare maskinkodeversjonen. Hvis du gjør endringer i programmet, må du kompilere det før du kan teste den endrede koden.

Et tolket språk er et der instruksjonene konverteres fra det du har skrevet til maskinkode mens programmet kjøres. Et tolket språk får i utgangspunktet en instruksjon fra programkilden, konverterer det til maskin kode, kjører maskinkoden og tar deretter neste instruksjon fra kilden for å gjenta prosess.

En variant bruker en totrinns prosess. Med denne varianten blir kilden til programmet ikke samlet direkte i maskinkoden, men i stedet blir konvertert til et forsamlingslignende språk som fremdeles er uavhengig av det aktuelle prosessor. Når du vil kjøre koden, behandler den den kompilerte koden gjennom en tolk som er spesifikk for prosessoren for å få maskinkoden som passer den prosessoren. Denne tilnærmingen har mange av fordelene ved å samle mens de opprettholder prosessoren uavhengighet siden den samme kompilerte koden kan tolkes av mange forskjellige prosessorer. Java er ett språk som ofte bruker denne varianten.

Den andre varianten kalles en Just in Time-kompilator (eller JIT). Med denne tilnærmingen kjører du faktisk ikke kompilatoren etter at du har skrevet koden. I stedet skjer det automatisk når du kjører koden. Ved å bruke en Just in Time-kompilator tolkes ikke koden setning etter setning, den er samlet i ett gå hver gang det blir kalt å bli kjørt, og så er det den kompilerte versjonen som den nettopp opprettet løpe. Denne tilnærmingen får det til å se mye ut som koden tolkes bortsett fra at i stedet for at det bare blir funnet feil når uttalelsen med feil oppnås, eventuelle feil som oppdages av kompilatoren resulterer i at ingen av koden kjøres i stedet for at all koden frem til det punktet blir løpe. PHP er et eksempel på et språk som vanligvis bare brukes i tidssamling.

Så nå vet vi hva tolket kode og kompilert kode betyr, spørsmålet vi neste trenger å svare på er hva har alt dette å gjøre med JavaScript? Avhengig av nøyaktig hvor du kjører JavaScript, kan koden samles eller tolkes eller bruke en av de to andre variantene som er nevnt. Det meste av tiden er dukjører JavaScript i en nettleser og der blir JavaScript vanligvis tolket.

Tolkede språk er vanligvis tregere enn kompilerte språk. Det er to grunner til dette. For det første må koden som skal tolkes faktisk tolkes før den kan kjøres, og for det andre skal skje hver gang uttalelsen skal kjøres (ikke bare hver gang du kjører JavaScript, men hvis den er i en Løkke så må det gjøres hver gang rundt løkken). Dette betyr at kode skrevet i JavaScript vil gå tregere enn kode skrevet på mange andre språk.

Hvordan hjelper det å vite dette hvor JavaScript er det eneste språket vi kan bruke på alle nettlesere? Selve JavaScript-tolken som er innebygd i nettleseren, er ikke skrevet i JavaScript. I stedet er det skrevet på et annet språk som den gang ble satt sammen. Hva dette betyr er at du kan få JavaScript til å kjøre raskere hvis du kan dra nytte av kommandoene som JavaScript gir som lar deg laste av oppgaven til selve JavaScript-motoren.

Et eksempel på dette er at noen, men ikke alle nettlesere, har implementert en document.getElementsByClassName () -metode i JavaScript-motoren, mens andre ennå ikke har gjort det. Når vi trenger denne funksjonaliteten, kan vi finne ut at koden kjøres raskere i nettleserne der JavaScript-motoren gir den ved å bruke funksjonen sensing for å se om metoden allerede eksisterer og bare lage vår egen versjon av den koden i JavaScript når JavaScript-motoren ikke gir den for oss. Der JavaScript-motoren gir den funksjonaliteten, bør den kjøre raskere hvis vi bruker den i stedet for å kjøre vår egen versjon skrevet i JavaScript. Det samme gjelder all behandling som JavaScript-motoren gjør tilgjengelig for oss å ringe direkte.

Det vil også være tilfeller der JavaScript gir flere måter å lage samme forespørsel på. I disse tilfellene kan en av måtene å få tilgang til informasjonen være mer spesifikk enn den andre. For eksempel document.getElementsByTagName ('tabell') [0] .tBodies og document.getElementsByTagName ('tabell') [0] .getElementsByTagName ('tbody') begge hente den samme nodelisten til tbody-kodene i den første tabellen på websiden, men den første av disse er en spesifikk kommando for å hente tbody-kodene der det andre identifiserer at vi henter tbody-tagger i en parameter og andre verdier kan erstattes for å hente andre tags. I de fleste nettlesere kjører den kortere og mer spesifikke varianten av koden raskere (i noen tilfeller mye raskere) enn den andre varianten, og det er derfor fornuftig å bruke den kortere og mer spesifikke versjon. Det gjør også koden lettere å lese og vedlikeholde.

Nå i mange av disse tilfellene vil den faktiske forskjellen i behandlingstiden være veldig liten, og den vil bare være når legger du til mange slike kodevalg sammen som du vil få noen merkbar forskjell i tiden koden tar løpe. Det er ganske sjelden at det å endre koden for å få den til å løpe raskere vil gjøre koden betydelig lengre eller vanskeligere å vedlikeholde, og ofte vil det motsatte være sant. Det er også den fordelen at fremtidige versjoner av JavaScript-motorer kan opprettes for å fremskynde den mer spesifikke varianten til og med videre slik at bruk av den spesifikke varianten kan bety at koden din vil kjøre raskere i fremtiden uten at du trenger å endre noe.