-
Data: 2012-03-28 08:51:52
Temat: wydajnosc wyjatkow
Od: "M.M." <m...@g...pl> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]Czesc
Kiedyś dawno z lat temu 10 albo jeszcze dawniej, przeczytałem
straszną rzecz o wyjątkach w C++. Pisał sam Lippman więc się trochę
przejąłem. Pisał on mianowicie że po włączeniu wyjątków skompilowany
program nie zmieścił się w pamięci ram. Nie zastanawiając się głębiej
uznałem że wyjątki wiążą się z jakimś narzutem i gdy była ważna
szybkość działania programu to ich nie używałem.
Teraz gdy się zastanawiam to wydaje mi się kompletnie bezsensowne aby
wyjątki wiązały się z jakimś dużym narzutem. Do czego ten narzut niby jest
potrzebny?
Gdy kompilator napotyka instrukcję try to co musi zrobić? Moim zdaniem
musi gdzieś zapamiętać adres wejścia do sekcji catch. Coś takiego
chyba najlepiej zapamiętać na jakimś stosie. Więc dużo zależy od tego
jak stos jest realizowany. Jeśli odkładanie elementu na stos jest
związane z malloc to mamy narzut taki sam jaki narzut ma malloc. Jeśli
stos jest budowany bez malloc to narzut jest pomijalny, wystarczy tylko
zapamiętać trochę danych, może z 20-30 bajtów.
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.
A co gdy kompilator napotyka throw Object? Zdaje się że musi odczytać
kolejno zapamiętane informacje przy napotkaniu try. Jeśli znajdzie
pasujący catch( Object ) to musi odtworzyć stos pointer. Potem na stos
odkłada Object i musi zrobić long jump do odpowiedniego catch.
Jednak wyjatki rzadko sie uaktywniają. Najczęściej mamy
if( false ) throw Object. Czy kompilator jak widzi ze w
procedurze jest throw Object to musi wygenerować jakiś
kod który się wykona pomimo że wyjątek nie będzie rzucony?
Moim zdaniem nie musi.
Gdzie tu jest problem z wydajnością, albo z ogromną pamięcią? Nie
mogę się doszukać. Lippman bzdury pisał czy ja czegoś nie rozumiem?
Pozdrawiam
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Następne wpisy z tego wątku
- 28.03.12 10:54
- 28.03.12 12:02 M.M.
- 28.03.12 13:04 Edek Pienkowski
- 28.03.12 15:32 M.M.
- 28.03.12 16:11 Edek Pienkowski
- 28.03.12 17:47
- 28.03.12 19:43
- 29.03.12 09:01
- 29.03.12 10:39
- 30.03.12 15:24 Adam Wysocki
- 30.03.12 15:49 M.M.
- 30.03.12 18:56 bartek szurgot
- 30.03.12 20:54
- 28.03.12 09:00 Roman W
- 28.03.12 12:18 Krzysiek Kowaliczek
Najnowsze wątki z tej grupy
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
- Ada 2022 Language Reference Manual to be Published by Springer
- Press Release - AEiC 2023, Ada-Europe Reliable Softw. Technol.
- Ada-Europe - AEiC 2023 early registration deadline approaching
- Ada-Europe Int.Conf. Reliable Software Technologies, AEiC 2023
- Ile cykli zajmuje mnożenie liczb 64-bitowych?
Najnowsze wątki
- 2024-06-05 [ot] spec od renowacji/reperacji kurtek skorzanych
- 2024-06-05 Koszt przywrócenia wychodnego numerowi w Plusie
- 2024-06-06 korki prawie takie same
- 2024-06-05 Takie elektryki mają sens ale czy z Francuską MARŻĄ?
- 2024-06-05 Warta S.A. - przyjęta odpowiedzialność?
- 2024-06-04 nie zna życia ten
- 2024-06-06 A jednak nie kondensatory
- 2024-06-06 Re: A jednak nie kondensatory
- 2024-06-06 Wymiana SIM Aero2
- 2024-06-06 Gdańsk => Programista Full Stack .Net <=
- 2024-06-06 Warszawa => Senior React Native Developer <=
- 2024-06-06 Gdańsk => Head of International Freight Forwarding Department <=
- 2024-06-06 Warszawa => Kierownik Działu Spedycji Międzynarodowej <=
- 2024-06-05 Olsztyn => Sales Specialist <=
- 2024-06-05 Ulm => Integration & Test Engineer <=