Edek Pienkowski <e...@g...com> napisał(a):

> Dzisiaj różnica w szybkości działania jest prawie żadna, o ile
> wyjątek nie jest rzucony. Jest narzut na obsługę wyjątku w postaci
> kodu obsługującego (czy masło jest wystarczająco maślane? ;) i
> straconych optymalizacji - to już zależy od języka i implementacji
> wyjątków.
Dziękuję z utwierdzenie mnie w tym przekonaniu :)

> Musi być kod robiący wszystko to, co jest przewidziane. W C++ oznacza
> to destrukcję lokalnych obiektów, sprawdzenie catch-clauses i
> unexpected-handlera, poza samym stack unwind.
No tak, ale to wszystko musi także wykonać bez wyjątków w
momencie gdy napotyka return? Hmmm a tak na marginesie gdy napotyka
longjump to co robi? Też robi destrukcje obiektów na stosie?


> > Gdy kompilator napotyka koniec sekcji catch to co musi zrobić? Chyba tylko
> > musi usunąć ze stosu to co wcześniej na nim zapamiętał. Więc o wydajności
> > decyduje sposób w jaki to kompilator zapamiętuje.


> (?) Nie kompiluje mi się to co napisałeś.
Nie wiem dokładnie jak nowoczesne kompilator/optymalizatory realizują obsługę
wyjątków. Wyobrażam sobie to jako jakąś strukturę stosową. Gdy
wykonanie programu dochodzi do sekcji try to na tą strukturę odkładana
jest jakaś informacja. Więc gdy wykonanie programu dojdzie do końca
sekcji catch to coś z tej struktury stosowej musi zdjąć. Jest to
związane z jakimś narzutem. Nie wiem na pewno, ale wydaje się że ów
narzut jest bardzo mały.

> Sam fakt, że wyjątek ma stos zmienia optymalizacje. W c++
> stos zależy od optymalizacji; w Javie generalnie nie, ale czasami
> tak.
Hmmmm zapewne tak. Ale czy to nie jest podobne utrudnienie optymalizacji
dla kompilatora jak po dodaniu instrukcji if? Kompilator generuje gorszy
kod gdy są wyjątki?

> Sam fakt, że JIT domyślnie upraszcza zachowanie tak, że zmienia
> semantykę NPE, świadczy o tym, że architekci uznali że warto.
Hmmm to chyba jednak zrobię kiedyś przy okazji jakiś mały benchmark :)

Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/