Co o tym myślicie: http://www.grush.one.pl/paperware/cppexceptions_pl_01.html
0
0
Pomiary nierzetelne, a wnioski calkowicie bledne!
Wyjatki sluza do reagowania na sytuacje wyjatkowe, wiec z definicji wywolywane sa b. rzadko. Dlatego polecenie throw moze wykonywac sie wolno i niczemu to nie szkodzi. Bledem jest tez zalozenie autora, ze sprawdzanie za pomoca if, czy funkcja wykonala sie prawidlowo, wprowadza maly narzut. Autor tego NIE PRZETESTOWAL, a gdyby to zrobil, to by sie okazalo, ze "if" bardziej spowolni program, niz umieszczenie sekcji try/catch (nawet w progr. rekurencyjnym). Jeden if moze spowolnic wywolanie funkcji kilkukrotnie!
Autor stosuje tez bardzo krotkie funkcje, ktore nic nie robia - czyli narzut wprowadzany przez wywolanie funkcji i wejscie w try/catch jest b. duzy w stosunku do kodu efektywnego. Dlatego wszelkie roznice sa b. silnie wyolbrzymione. 99% funkcji wykonuje sie kilka lub kilkunastokrotnie dluzej niz czas samego skoku do funkcji, dlatego sredni narzut try/catch jest rzedu 1% a moze nawet mniej. Jesli ktos robi krotkie funkcje, to wtedy robi je jako inline - tego autor nie sprawdzil, a kompilator przeciez traktuje te funkcje inaczej.
0
Pomiary nierzetelne, a wnioski calkowicie bledne!
Zrobilem wlasne testy i okazalo sie, ze wlaczenie wyjatkow nie spowalnia prawie w ogole (<2%) wywolania funkcji. Skompilowalem jeszcze progr. do assemblera i jedyne, co jest dorzucane, to na poczatku kazdej funkcji pare (ok. 8) prostych instrukcji przeslania (_get_eh_context). Zwykle te instrukcje waza sporo mniej (4-8 taktow procka w zaleznosci od architektury) niz skok (nawet do 60 taktow). Sprawa jest niepotrzebnie rozdmuchana.
Co do rozmiaru kodu, to koles cos mocno naciagnal. Program z jedna funkcja bez wyjatkow (gcc 2.95): 8 kB, z wyjatkami: 16 kB. W duzych programach narzut jest rzedu kilku procent tych 8 kB + kilka procent, a nie 2 razy jak napisane w artykule. Duze programy, to takie po 30 MB a nie 300 kB.
Widac, ze gosc sie nie zna i wypisuje bzdury. Eh...