Dnia pamiętnego Wed, 10 Jul 2013 01:00:35 -0700, Maciej Sobczak wyjmując
peta oznajmił:

> Trafiłem na fajny artykuł:
>
> http://sealedabstract.com/rants/why-mobile-web-apps-
are-slow/

Uff. Długawy?

> Dosyś długawy, ale w ramach wakacyjnego rozruszania grupy polecam.
> W szczególności tak gdzieś w połowie strony jest wykres pokazujący jak GC wpływa na
wydajność programu w zależności od pamięci, która jest dostępna w systemie w relacji
do tego, jaka jest faktycznie potrzebna.
>
> W ogóle jest tam trochę mocnych stwierdzeń. Sporo odniesień do wszelakich obecnie
używanych języków programowania. Polecam.

Może zacznę od tego, że nie wiem skąd wiedziałem że JS jest bliższy C++ niż 3-5x.

Gość też cytuje ostateczną lambdę, a tam niedawno był artykuł o dialekcie
JS stworzonym dokładnie w celu ominięcia ciężkich pod względem
wydajności punktów w języku. Co prawda komentarze mówiły o braku
"soundness proof" lub też niemożliwości uzyskania takiego, ale
niech to będzie WorkInProgress.

Natomiast gość cytuje wiele rzeczy i - co się podobuje - chce się trzymać
faktów, ale gdy przychodzi do metody benchmarków mówi "oczywista
oczywistość że liczenie md5 jest lepszym benchmarkiem niż harvest kodu
z tysiąca stron www". Co jest bzdurą, nie pamiętam linka ale benchmark
4 języków Google'a pokazał, jak złudne są syntetyki, trochę kombinatoryki
pomieszanej z rekurencją i nagle Java wychodzi poza obszar, do którego
była stworzona. Dla mnie oczywistą oczywistością jest fakt, że syntetyki
pokazują dobrze warunki brzegowe więc nadają się dla autorów kompilatorów,
ale potem przychodzi zonk prawdziwych aplikacji: w gcc odkryli, że
benchmark mozilli daje lepsze wyniki przy -Os niż -O2, co zdecydowanie
nie było ich intencją. Bo nie testowali dużego kodu tylko używali
syntetycznych benchmarków, tak jakby wszyscy niczym firr pisali
50-linijkowe programy.

Co do samego GC, nic nowego, ja bym powiedział że noGC aktualnie robi mi się
pod domem i niedługo nie będzie można okna otworzyć. Ale i tu gość trochę
nagina rzeczywistość. GC, to JVMa przynajmniej, ma kilka opcji, w tym
concurrent GC, które nie tylko nie powoduje przerw ale też - ponieważ sprząta
mniej więcej tak szybko jak przydziela pamięć - ma mniejsze wymagania co
do wolnej pamięci [1]. Wciąż potrzebuje dużej liczby obiektów nadających się
do zwolnienia, żeby mieć sensowną wydajność, ale umówmy się, że różne programy
mają różne podejście do alokacji. Część alokuje masę obiektów non-stop, część
alokuje praktycznie wszystko up-front a potem ma lokalne obiekty, które
formalnie są na stercie ale praktycznie trafiają na stos JITa, albo
jest ich po prostu niewiele.

Co oznacza tyle, że używanie GC nie zwalnia od myślenia o pamięci, nawet
jeżeli autorzy JVM odradzają pool-e obiektów (nic dziwnego) to nawet
w Javie warto czasami alokować obiekty rzadzaiej niż częściej (czytaj:
nie w wewnętrznej pętli), jeżeli mają być większe niż kilka B.

[1] Ok, wiem że link by się przydał, ale z tak wielkim rantem dzisiaj nie
podyskutuję.

--
Edek