Firefox 3.1 får ny hurtigere JavaScript-fortolker

En ny just-in-time-fortolker til JavaScript skal give en væsentlig forbedring af ydelsen på browserbaserede applikationer.

Den næste større opdatering af webbrowseren Firefox version 3.1 vil få en ny og hurtigere fortolker til JavaScript, som udvikles under kodenavnet TraceMonkey.

Der er tale om en fortolker, som skal give Firefox mulighed for at optimere ydelsen af JavaScript ved at benytte just-in-time-fortolkning, skriver magasinet eWeek.

Det vil kunne forbedre ydelsen af visse typer browsertunge JavaScript-applikationer tifoldigt, hævder udviklerne bag TraceMonkey.

Det er især Web 2.0 og AJAX, som har sat de eksisterende fortolkere af JavaScript under pres.

TraceMonkey-projektet ledes af teknisk direktør Brendan Eich fra Mozilla, som også udviklede den første JavaScript-fortolker SpiderMonkey til Netscape.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Thomas Ammitzbøll-Bach

Uden at vide hvordan det foregår i Firefox 3.1, vil jeg mene, at det er fortolkning til intern repræsentation under af vikling af programrutinerne.

De fleste "fortolkede" sprog i dag foretager en fortolkning forud for afviklingen til en intern repræsentation. Det kan være decideret mellemkode, eller det kan være et parse-træ. Nogle sprog kan både køre kildetekstprogrammer og gemme de intermediære form til en fil.

Jeg forstår udtrykket sådan, at det er ikke en decideret compiler, der oversætter til maskinkode, JBC eller sligt, men en fortolker, der producerer en intern repræsentation og afvikler fra denne, men at afviklingen begynder, før teksten er færdigfortolket.

Thomas

  • 0
  • 0
#4 Jonas Finnemann Jensen

jit (just-in-time-fortolkning) er så vidt jeg ved at man oversætter programmet til kode der kan afvikles ved program start... Hvilket gør at en funkion bliver udført hurtiger anden gang man kører den... Alternativet er normal fortolkning, hvor koden bare bliver udført linje for linje, hvilket således er langsommere når man udfører den sammen funktion mere end en gang...

Derudover er der i dynamisk sprog som javascript mulighed for specialisering, hvilket, af nogen, menes at kunne give bedre performance end statistiske sprog (dog stadig større hukommelses forbrug).

Synes der er en interessant udvikling... Måske web applikationer er kommet for at blive... Hvem ved...

  • 0
  • 0
#5 Andreas Ryge

Jeg troede der var andre end mig der kunne se det sjove...

Mozilla har inkluderet en just-in-time compiler - ikke en just-in-time fortolker....

Det giver ikke mening at tale om just-in-time fortolkning.

  • 0
  • 0
#6 Jesper Stein Sandal

Fortolker - oversætter

Er forskellen stor nok til at tale om begrebsforvirring, eller kritiserer du brugen af danske udtryk? Hvis DIKU giver grønt lys skal jeg gerne holde op med at oversætte it-begreber. Personligt synes jeg, det var slemt nok ikke at have en brugbar oversættelse af 'just-in-time'.

  • 0
  • 0
#7 Morten W. Jørgensen

Ja. Forskellen er faktisk stor. En fortolker tillader at kode med semantiske fejl afvikles da der, f.eks., ikke foretages typecheck før afviklingstidspunktet. Sådan forholder det sig ikke med oversatte sprog - typisk. Og netop det "typisk" gør dit spørgsmål om hvorvidt forskellen er så stor et godt spørgsmål. Grænserne er lidt flydende efterhånden syntes jeg, men en JIT fortolker er vist en pleonasme.

Derudover tror jeg ikke du skal tage Andreas kommentar som en kritik men nærmere en generel morsomhed over den allestede nærværende begrebsforvirring.

  • 0
  • 0
#9 Jacob Christian Munch-Andersen

Begrebet "fortolke" vil jeg umiddelbart opfatte som processon hvor hvert enkelt linje parses når den skal køres, hvorefter fortolkeren så udfører de tilsvarende kommandoer. (Super langsom proces)

For at forstå den omtalte innovation må man først forstå hvorfor JavaScript afvikles så langsomt. Man kan ikke bare kompilere JavaScript ligesom man kan kompilere alt muligt andet kode, JavaScript har nemlig et sæt af funktioner som gør det muligt at tage en streng med kildekode og køre denne kode 'on the fly'. Strengen med kode kan komme hvor som helst fra, den kan være sammensat under kørsel af en masse bidder på en masse forskellige måder som er totalt umuligt for kompileren at forudse.

Derfor er langt den letteste måde at implementere JavaScript på at lave en fortolker som behandler alt som strenge.

Den optimale løsning ville helt klart være at lave et nyt sprog som ikke kan afvikle strenge og som defor kan kompileres. Strengafvikling giver alligevel noget rodet kode, hvis man rigtigt udnytter det så laver man totalt uforståelig kode.

Den næstbedste løsning er at kompilere så meget som muligt og så ellers kompilere kode som passer sammen med den gamle kode hver gang der kommer en ny streng kildekode. Så vidt jeg har forstået er det den løsning de nu hiver fat i. Det er helt klart lettere sagt end gjort, der skal genereres maskinkode direkte, og den kode skal være forberedt på at der kommer nye stykker til under kørslen.

  • 0
  • 0
#10 Torben Mogensen Blogger

En fortolker tillader at kode med semantiske fejl afvikles da der, f.eks., ikke foretages typecheck før afviklingstidspunktet. Sådan forholder det sig ikke med oversatte sprog - typisk.

Der er mange fortolkere, der laver semantisk check (typecheck osv.) inden fortolkningen starter. Det giver selvklart en kort pause inden den egentlige programudvikling, men i reglen ikke noget, der mærkes. Selv visse BASIC fortolkere i hjemmecomputere fra 80'erne lavede sådanne check. Den svenske ABC80 computer checkede f.eks. inden kørsel, at alle hop skete til linjer, der eksisterede i programmet.

  • 0
  • 0
#11 Torben Mogensen Blogger

Begrebet "fortolke" vil jeg umiddelbart opfatte som processon hvor hvert enkelt linje parses når den skal køres, hvorefter fortolkeren så udfører de tilsvarende kommandoer. (Super langsom proces).

Sådan er der (næsten) heller ikke nogen fortolkere, der virker. Programmet bliver i reglen indlæst og konverteret til en syntaktisk repræsentation, som er hurtigere at fortolke end den rå tekst. Selv BASIC fortolkerne i firserhjemmecomputere gjorde det (se ovenstående indlæg for et eksempel). Som minimum (som i f.eks. Commodore BASIC og BBC BASIC) gjordes det, der svarer til leksikalsk analyse, hvor hvert nøgleord blev konverteret til en enkelt byte, og hvor talkonstanter blev konverteret til maskintal (binær). Endvidere blev programlinjerne lagt i en hægtet liste, så man hurtigt kunne søge gennem linjerne. Ovennævnte ABC80 konverterede endvidere variabelnavne og linjenumre i GOTO-sætninger til maskinadresser, så variabeltilgang og hop skete hurtigere.

Grænsen mellem oversættere og fortolkere er ret flydende, og mange implementeringer bruger begge dele: Oversættelse til bytekode og derefter fortolkning af denne.

  • 0
  • 0
Log ind eller Opret konto for at kommentere