Názory k článku
Do hlubin implementací JavaScriptu: 1. díl - úvod

Nedávno jsem implementoval možnost přesunu řádku v tabulce nahoru, dolu ,úplně nahoru a úplně dolů. Jako nástroj na pomoc jsem zvolil jQuery v poslední verzi (1.2.6) kvůli usnadnění práce s DOM. Výsledkem je cca 100 řádkový script. Blbé je, že na tomto scriptu je vidět rozdíl v rychlost zpracování JS pod Chrome nebo Safari vše běhá nádherně svižně. Pod IE 7 nebo Firefox 3 je rychlost nesrovnatelně pomalejší. Třeba při přesunu řádku v tabulce z horní pozice až dolů přes 70 řádků musí uživatel čekat klidně i 2 sekundy a s narůstajícím počtem řádků v tabulce toto číslo stoupá. Takže doufám, že optimalizace rychlosti se dočkáme i v jiných prohlížečích než jen těch založených na Webkit-u. A idální by bylo kdyby se tyto změny dostali i do starších bverzí těchto prohlížeču.

Zapoměl jsem se přihlásit předchozí příspěvek je ode mě.

2 sekundy? V ideálním případě to je 1x removeChild a 1x appendChild (insertBefore), to musí být hned. Chybu bych hledal v tom 100 řádkovým scriptě. :)

Presne tak. Hlavne na taku malu vec nahravat zo serveru jQuery, mi pride strasne. Samozrejme pokial autor pouziva tuto kniznicu aj na inom mieste, tak to ma vyznam.

A co "rendering engine"? Chyba predsa vobec nemusi byt ani v skripte and v JS, ale prave v zobrazeni 70 riadkovej tabulky.

Nemohl byste při tom srovnávání zmínit i Rhino? Docela by mě zajímalo, jak si stojí a co si o tomto projektu vůbec myslet. Díky!

Toto je dost odvazne tvrdenie: Ze širšího pohledu je také velice zajímavé, že zrychlování JavaScriptu posouvá "state-of-art" v oblasti interpretace dynamických jazyků obecně. Dynamické skriptovací jazyky (kam JavaScript patří) totiž obvykle slouží jen jako "lepidlo" komponent napsaných v jiných, rychlejších jazycích. Jejich rychlost tak není kriticky důležitá a tím pádem se výzkum v oblasti jejich interpretace nedostal příliš daleko - na rozdíl od oblasti kompilace "klasických" statických jazyků, která je intenzivně zkoumána přes 30 let.

Tak toto mi pride trochu pritiahnute za vlasy. Smalltalk je dufam dostatocne dynamicky jazyk a domnievam sa, ze by mohol hravo sutazit s JS zo Safari, WebKitu, Firefoxu a Opery. Staci si spustit lubovolny smalltalk - cele IDE je implementovane samozrejme v smalltalku. Je sice kompilovany do byte-kodu, ale samozrejme, ze nehovorim o nejakom javac'n'java kompilovani a nikto dufam nebrani prehliadacom pouzit JIT.

Odporucam sa pozriet na Just-in-time_compilation#History. V kazdom pripade by som si netrufol napisat, ze interpretacia dynamickych jazykov sa daleko nedostala, ani ze JavaScript nejak moc k tomu prispel/prispeje. [FLAME]Mozno konecne aj "jazycky" ako Python a Ruby trochu dotiahnu na Jazyk.[/FLAME]

Pre lenivych: Sun's Self language improved these techniques extensively and was at one point the fastest Smalltalk system in the world; achieving up to half the speed of optimized C^[2] but with a fully object-oriented language.

A je Smalltalk taky skriptovací? :)

Taky to moc nechápu. Co to vlastně znamená skriptovací, když v JS skripty asi taky nikdo moc nepíše? A co je to dynamický jazyk? A proč musí být interpretovaný, co brání v tom ho zkompilovat? A neexistují už náhodou kompilované verze? Je kompilovaný Common Lisp dynamický?

"JavaScript je první dynamický jazyk, jehož rychlost je klíčová a zároveň je dostatečně rozšířený na to, aby vznikla dostatečná poptávka po tom ho významně zrychlit." - i v tom odkazovaném blogu je zmínka o C-like speedu u kompilátoru historického dynamického jazyka, takže ta potřeba tu už asi byla dřív, a investovaného úsilí nebylo zas tak málo, a upravován byl i jazyk, ne jen kompilátory. Například dokud v Javascriptu nebudou nepovinné deklarace typu (nebo tam už jsou?), tak jeho kompilátory asi nebudou moci jít tak "na krev" jako ty historických dynamických jazyků.

Aby nedošlo k omylu - to s čím ne zcela souhlasím jsou jen detaily, na seriál se těším, vypadá to zajímavě.

A co je to vlastně ten tracing? V článku je jen zmíněn, v odkázaném blogu o tom taky není... snad příští díl.

> dokud v Javascriptu nebudou nepovinné deklarace typu

Neukázalo se při implementaci Strongtalku, že po všech optimalizacích typu PIC (které se mimochodem používá i ve V8) jsou optimalizace na základě typových informací zbytečné? :-)

Jinak hezký článek o trace trees je třeba tohle FAQ.