Betydelse av tolkat eller kompilerat i JavaScript

Datorer kan faktiskt inte köra koden du skriver i JavaScript (eller något annat språk för den delen). Datorer kan bara köra maskinkod. Maskinkoden som en viss dator kan köra definieras i processorn som kommer att köra dessa kommandon och kan vara olika för olika processorer.

Självklart, skrivmaskin kod var svårt för människor att göra (är 125 ett tilläggskommando eller är det 126 eller kanske 27). För att komma runt det problemet skapades vad som kallas montagespråk. Dessa språk använde mer uppenbara namn för kommandona (som ADD för att lägga till) och avlägsnade därmed behovet av att komma ihåg de exakta maskinkoderna. Monteringsspråk har fortfarande en till en-relation med den specifika processor och maskinkod som datorn konverterar dessa kommandon till.

Församlingsspråk måste kompileras eller tolkas

Mycket tidigt insåg man att det var lättare att skriva språk behövdes och att datorn själv kunde användas för att översätta dem till maskinens kodinstruktioner som datorn faktiskt kan förstå. Det fanns två tillvägagångssätt som kunde tas med denna översättning och båda alternativen valdes (antingen det ena eller det andra kommer att användas beroende på vilket språk som används och var det körs).

instagram viewer

Ett sammanställt språk är ett språk där när programmet har skrivits matar du koden genom ett program som heter a kompilator och som producerar en maskinkodversion av programmet. När du vill köra programmet så kallar du bara maskinkodversionen. Om du gör ändringar i programmet måste du kompilera det igen innan du kan testa den ändrade koden.

Ett tolkat språk är ett där instruktionerna konverteras från det du har skrivit till maskinkod när programmet körs. Ett tolkat språk får i princip en instruktion från programkällan, konverterar det till maskin kod, kör den maskinkoden och tar sedan nästa instruktion från källan för att upprepa bearbeta.

Två varianter på sammanställning och tolkning

En variant använder en tvåstegsprocess. Med den här varianten sammanställs källan till ditt program inte direkt i maskinkoden utan istället konverteras till ett församlingsliknande språk som fortfarande är oberoende av det specifika processor. När du vill köra koden bearbetar den den kompilerade koden genom en tolk som är specifik för processorn så att maskinkoden passar den processorn. Detta tillvägagångssätt har många av fördelarna med att sammanställa samtidigt som processorns oberoende bibehålls, eftersom samma sammanställda kod kan tolkas av många olika processorer. Java är ett språk som ofta använder den här varianten.

Den andra varianten kallas en Just in Time-kompilator (eller JIT). Med den här metoden kör du faktiskt inte kompilatorn efter att du har skrivit din kod. Istället sker det automatiskt när du kör koden. Med hjälp av en Just in Time-kompilator tolkas inte koden uttalande efter uttalande, den sammanställs allt i ett gå varje gång det kallas att köras och sedan är den kompilerade versionen som den just skapade det som blir springa. Den här metoden gör att det ser mycket ut som att koden tolkas förutom att istället för att fel bara hittas när uttalandet med fel uppnås, eventuella fel som upptäcks av kompilatorn resulterar i att ingen av koden körs istället för att hela koden fram till den punkten är springa. PHP är ett exempel på ett språk som vanligtvis bara används i tidskompilering.

Är JavaScript kompilerat eller tolkat?

Så nu vet vi vad tolkad kod och kompilerad kod betyder. Frågan vi nästa måste svara är vad har allt detta att göra med JavaScript? Beroende på exakt var du kör din JavaScript kan koden sammanställas eller tolkas eller använda någon av de två andra varianterna som nämns. Det mesta du ärkör din JavaScript i en webbläsare och där tolkas JavaScript vanligtvis.

Tolkade språk är vanligtvis långsammare än sammanställda språk. Det finns två skäl till detta. För det första måste koden som ska tolkas faktiskt tolkas innan den kan köras och för det andra att hända varje gång uttalandet ska köras (inte bara varje gång du kör JavaScript utan om det är i en slinga då måste det göras varje gång runt slingan). Detta innebär att kod som skrivs i JavaScript kommer att gå långsammare än kod som skrivs på många andra språk.

Hur kan kunskap om detta hjälpa oss där JavaScript är det enda språket som finns tillgängligt för alla webbläsare? Den JavaScript-tolkaren som är inbyggd i webbläsaren är inte skriven i JavaScript. Istället är det skrivet på något annat språk som sedan sammanställdes. Vad detta innebär är att du kan få din JavaScript att köra snabbare om du kan dra nytta av kommandon som JavaScript tillhandahåller som gör att du kan ladda ner uppgiften till själva JavaScript-motorn.

Exempel för att få JavaScript att köra snabbare

Ett exempel på detta är att vissa men inte alla webbläsare har implementerat en document.getElementsByClassName () -metod i JavaScript-motorn medan andra ännu inte har gjort det. När vi behöver den här funktionen kan vi göra att koden körs snabbare i de webbläsare där JavaScript-motorn tillhandahåller den med hjälp av funktionen avkänning för att se om metoden redan finns och bara skapa vår egen version av den koden i JavaScript när JavaScript-motorn inte tillhandahåller den oss. Där JavaScript-motorn tillhandahåller den funktionen bör den köra snabbare om vi använder den snarare än att köra vår egen version skriven i JavaScript. Detsamma gäller för alla behandlingar som JavaScript-motorn gör att vi kan ringa direkt.

Det kommer också att finnas fall där JavaScript ger flera sätt att göra samma begäran. I dessa fall kan ett av sätten att få tillgång till informationen vara mer specifikt än det andra. Till exempel document.getElementsByTagName ('tabell') [0] .tBodies och document.getElementsByTagName ('tabell') [0] .getElementsByTagName ('tbody') båda hämta samma nodelist för tbody-taggarna i den första tabellen på webbsidan, men det första av dessa är ett specifikt kommando för att hämta tbody-taggarna där den andra identifierar att vi hämtar tbody-taggar i en parameter och andra värden kan ersättas för att hämta andra taggar. I de flesta webbläsare kommer den kortare och mer specifika varianten av koden att köras snabbare (i vissa fall mycket snabbare) än den andra varianten och så är det vettigt att använda den kortare och mer specifika version. Det gör också koden lättare att läsa och underhålla.

I många av dessa fall kommer den faktiska skillnaden i behandlingstid att vara mycket liten och det kommer bara att vara när lägger du till många sådana kodval tillsammans som du kommer att få någon märkbar skillnad i den tid din kod tar springa. Det är ganska sällsynt att om du ändrar din kod så att den går snabbare kommer koden att bli betydligt längre eller svårare att underhålla, och ofta kommer det omvända att vara sant. Det finns också den fördelen att framtida versioner av JavaScript-motorer kan skapas som snabbar upp den mer specifika varianten vidare så att användning av den specifika varianten kan innebära att din kod kommer att köras snabbare i framtiden utan att du behöver ändra något.