Det er mange faktorer som påvirker hvor rask en nettleser oppleves. Blant disse er hvor raskt nettleseren greier å kjøre enkle og mer komplekse rutiner basert på JavaScript.
De siste månedene har det vært en rivende utvikling på dette feltet, og så godt som samtlige aktører har stor fokus på dette området.
Apple var tidlig ute med å kunngjøre løfter om en raskere JavaScript-motor i selskapet Safari-nettleser. I juni lovet selskapet at Safari 4.0 skal tilby en JavaScript-ytelsen som er opptil 53 prosent høyere enn i dag.
Det spørs om ikke Apple har vært for forsiktige.
Safari er basert på friprog-prosjektet WebKit, som også utgjør mye av grunnlaget for Googles Chrome-nettleser. Dette prosjektet har laget en JavaScript-motor som kalles SquirrelFish, og det er ytelse til denne Apple viser til i kunngjøringen i juni.
I forrige uke ble det klart at WebKit-prosjektet ikke har tenkt å gi seg med dette. I et blogginnlegg skriver Maciej Stachowiak, som er tilknyttet WebKit-prosjektet, om en videreutvikling av SquirrelFish, nemlig SquirrelFish Extreme.
Testresultatet Stachowiak har gjengitt, viser at SquirrelFish Extreme kjører den kjente JavaScript-testen Sunspider mer enn dobbelt så raskt som SquirrelFish og mer enn ti ganger så raskt som WebKit 3.0, som kom for omtrent et år siden.
Ytelsesforbedringene er blitt oppnådd i hovedsak ved å ta i bruk fire ulike teknikker.
Den ene dreier seg om optimaliseringer på bytekode-nivå. Mange JavaScript-operasjoner oppfører seg forskjellig i mange ulike tilfeller. Ved å sjekke de mest vanlige og raskeste tilfellene først, har man greid å øke ytelsen en hel del. I tillegg er bytekode-instruksjonssettet blitt forbedret, og det er blitt laget optimaliseringer som utnytter disse forbedringene.
SquirrelFish Extreme tar også i bruk det som kalles en Polymorphic Inline Cache. I SquirrelFish Extreme brukes dette til å gjøre raskere oppslag til egenskaper i objekter med samme struktur - det vil si samme egenskaper i samme rekkefølger. Metoden er raskere enn å gjøre hashoppslag i hvert enkelt tilfelle.
Den tredje teknikken kalles Context Threaded JIT (Just In Time). Dette går i bunn og grunn ut på å konvertere bytekode til systemspesifikk kode, én operasjonskode om gangen. Komplekse operasjonskoder konverteres om til funksjonskall inn i språkets runtime-omgivelser. Enkle operasjonskoder kan settes direkte inn i strømmen av systemspesifikk kode. Dette skal redusere kostnader knyttet til CPU-en ekspedering av koden, i tillegg til at flere forgreninger i koden gjøres mer forutsigbare for CPU-en.
Bare 4000 linjer av JIT-en er knyttet til genereringen av systemspesifikk kode. Resten er kryssplattform kode, selv om JIT-en foreløpig bare er blitt laget for x86 32-bit.
Den fjerde teknologien er bruken av den samme JIT-infrastrukturen i en kompilator for regulære uttrykk. Dette skal gi opptil 5 ganger høyere ytelse ved sammenligninger basert på regulære uttrykk.
Flere detaljer om de fire teknikkene som er blitt tatt i bruk, finnes her.
På denne siden har WebKit-prosjektets Cameron Zwarich sammenlignet ytelsen til SquirrelFish Extreme med Googles V8-motor og Mozillas TraceMonkey, samt Opera 9.6 beta. SquirrelFish Extreme kommer klart best ut, mens Opera 9.6 beta henger svært langt etter i Zwarichs test. Ingen av de testede produktene har blitt lansert ennå. Det er grunn til å tro at samtlige vil optimaliseres ytterligere før en lansering.
Les også:
- [01.03.2010] Slik skal Firefox bli mye raskere
- [05.02.2009] Opera får mye raskere Javascript-motor
- [19.12.2008] Google trapper opp nettleserkrigen
- [26.09.2008] Endelig fulltreff for WebKit i Acid3-testen
- [09.09.2008] Raskere nettlesere skaper måleproblemer
- [25.08.2008] Lover lynrask JavaScript i Firefox 3.1
- [27.06.2008] Ajax-ytelse vil avgjøre nettleserkampen
