[G.....n]

V8 lepiej radzi sobie z WeakMap i Map jeśli wszystkie klucze są tego samego typu.

#javascript #v8

[Marmite]

@Ginden: Chyba wszystko w JSie jest lepiej optymalizowane jeśli jest tego samego typu. No ale po co nam statyczne i ścisłe typowanie, kto by tego używał...

[P0lip]

statyczne i ścisłe typowanie

@Marmite: Dla początkujących byłaby to mordęga (na początku), ale później dużo plusów. Mogliby chociaż zrobić tak jak w pythonie - silne typowanie.

[Marmite]

@P0lip: Chrzanić początkujących, skoro nawet ludzie którzy siedzą w JSie jakiś czas nie umieją w nim pisać dobrze :P (#potwierdzoneinfo, chociażby za każdym razem kiedy otwieram jakieś zapomniane, dawno nie oglądane pliki z obecnego projektu).

No cóż, mamy luźne, dynamiczne typowanie i musimy z tym żyć. Dobrze że chociaż silniki jakoś próbują sobie z tym radzić (hidden class, optymalizacje, itp.), no ale to wymaga pisania czystego kodu. Więc paradoksalnie w

[P0lip]

@Marmite: dobrze, że powstają takie projekty jak asm.js - to już jakiś krok naprzód

[Marmite]

@P0lip: Ale nie oszukujmy się i nie patrzmy na to zbyt kolorowo, to tylko gorączkowe próby, hacki, żeby JS był bardziej używalny niż jest :D

[P0lip]

@Marmite: No racja. Największą porażką i tak jest fakt, że wszystkie nowe funkcje, które są baaaardzo przydatne i tak są póki co nieużywalne ze względu na kompatybilność :D

[Marmite]

@P0lip: Zgadza się. Niestety JSem zacząłem się interesować jak już ES5.1 było dosyć dobrze zadomowione, więc nie mam pojęcia jak wyglądała i ile zajęła przesiadka z ES3 na ES5. Teraz przy okazji ES6 wydaje się to ciągnąć w nieskończoność. A biorąc pod uwagę że specyfikację planuję wydać dopiero w czerwcu 2015 (pozdro, miała być gotowa pod koniec 2013) to polyfillów i innych shimów do ES6 będziemy pewnie używać do 2016.

Dobrze,

[P0lip]

@Marmite: Ja też JSem się zacząłem interesować od niedawna, więc również nie wiem jak to wyglądało. IE, by mogli na Linuxa wydać to nie musiałbym chociaż co chwilę wirtualnej maszyny włączać, żeby debugować. Niemniej MS i tak źle zrobił, że nie wydał choćby 9 dla XP'ka, to może 8mka by szybciej znknęła, a tak to nadal 4-5% w Polsce.

A tak swoją drogą, to kiedyś czytałem jak kiedyś na rozmowie o

[P0lip]

@Marmite: A i tak swoją drogą, robisz jakieś optymalizacje dla poszczególnych przeglądarek/silników? W sensie, że np. jedna funkcja dla spidermonkey jest nieco inna niż inna robiąca ta samo w v8

[Marmite]

Nawet na blogu (csstricks) autor pisał coś takiego $("a[href]") zamiast $(document.links)

@P0lip: No i nawet lepiej, że tak pisał :P

document.links

to nie dość, że częśc nie do końca związana z samym JSem (bo to DOM API), to jeszcze jest to stara wersja DOM API. Też bym tego nie używał :P jak już to

document.querySelectorAll("a[href]")

, ale warto wspomnieć, przeglądarki udostępniają właśnie tę funkcję (czy tam

document.querySelector

) pod

$

.

[P0lip]

@Marmite: 1. ale duuuużo wydajniejsze :P

2. Czekam z niecierpliwością. Zależy też od targetu, jeśli chodzi o urządzenia mobilne to te kilka ms daje jakąś różnicę, zwłaszcza, gdy jest stary aparat

[Marmite]

1. ale duuuużo wydajniejsze :P

@P0lip: No, nie do końca. Przeglądałeś kiedyś kod Sizzle (silnika selektorów z jQuery)? Jeśli tylko jest w stanie, to pod spodem korzysta właśnie z

document.querySelectorAll

. Oczywiście i tak dochodzą koszty zamiany

NodeList

na instancję

jQuery

i jeszcze kilka innych rzeczy, ale nie przesadzajmy ;)

EDIT: a, chyba że mówisz o

document.links

. No, ale to jest stare API :D

[P0lip]

@Marmite: Miałem okazję. Co do document.links to jest szybszy ~ 1.5x - zwłaszcza greasemonkey

Zresztą zawszę korzystam z natywnych metod jeśli dostępne (w sensie wszystkie poza querySelector/All), bo są szybsze, a jeśli chodzi o kompatybilność to zawsze robię sobie teścik mały i jeśli coś się nei zgadza to korzystam z querySelector. Trochę jest babrania się z tym, ale na moim starym smartphonie widać różnicę jeśli aplikacja jest bardzo duża.

[Marmite]

Co do document.links to jest szybszy ~ 1.5x

@P0lip: To jest całkiem dobry argument żeby używać go w krytycznych miejscach aplikacji, zwłaszcza na mobile'ach.

[P0lip]

@Marmite: Tak, mi głównie chodzi o mobilne urządzenia. Na pc'tach nie ma różnicy tak naprawdę

[P0lip]

http://jsperf.com/document-links-vs-document-queryselectorall-a/5 zobacz na FF jaka jest różnica. Na v8 nie ma żadnej, ale greasemonkey co innego

[Marmite]

@P0lip: Jakby co to Greasemonkey to nie jest silnik Firefoxa, bo mam wrażenie że właśnie w tym znaczeniu używasz tego terminu :P jeśli tak nie jest, to nie mam pojęcia co ma do tego Greasemonkey i jak to zmierzyłeś :P

[P0lip]

@Marmite: Spidermonkey miałem na myśli:D

Na jsperf mierzyłem i swoje testy

[P0lip]

@Marmite: http://jsperf.com/document-links-vs-document-queryselectorall-a/5 na dół sobie zjedź i run tests. W v8 wychodzi bardzo podobnie, ale na spidermonkey co innego zupełnie. Podobnie jest z własnymi testami.

Zasadniczo różnica bierze się z tego, że dodaje się [href], bo tak to getElementsByTagName("a") jest szybsze od document.anchors i querySelectorAll("a"), z tym że wtedy można dostać anchors bez hrefów

[G.....n]

@P0lip: DOM API nie ma dużo wspólnego z V8 czy SpiderMonkey i testy jego wydajności mierzą wydajność kodu C++.