Wieviel Zeit brauchen Try...Catch...Finally?
| Tutorial | |
|---|---|
| Wieviel Zeit brauchen Try...Catch...Finally? | |
| Autor | Roland "Glatzemann" Rosenkranz |
| Programmiersprache | C# |
| Kategorie | XNA Tutorials |
| Diskussion | Thread im Forum |
| Lizenz | indiedev article license |
| MitOhneHaare.de | |
Die Fehlerbehandlung mit Try...Catch...Finally stand bei mir immer unter dem Verdacht, einiges an Performance zu fressen. Warum dies so ist, kann ich nicht genau sagen. Jedenfalls habe ich anlässlich eines Threads auf XNA.mag einfach mal einen Benchmark durchgeführt um die unterschiedlichen Arten der Fehlerbehandlung einem Test zu unterziehen und einfach mal auszuprobieren, welche Art am schnellsten ist.
Verwendet habe ich dazu ein Benchmark-Framework, daß ich vor langer Zeit mal entwickelt habe um genau solch einfachen Dinge schnell und effektiv testen zu können.
Index - Description - Ticks Total - Ticks/Operation - ms Total - ms/Operation 1 - without exception handling: 10261246, 10, 4776, 0 2 - with exception handling: 10458052, 10, 4867, 0 3 - with exception handling and finally: 10650060, 10, 4957, 0 4 - with multi exception handling: 10227597, 10, 4760, 0
Die Test sollten mehr oder weniger selbsterklärend sein. Ohne Exception-Handling, dann mit, dann zusätzlich ein finally und zu guter letzt mit mehreren Catch-Anweisungen für unterschiedliche Exceptions.
Die Werte liegen alle so nah beieinander, daß man von Meßungenauigkeiten reden kann. Fakt ist jedenfalls, daß eine Fehlerbehandlung als solche die Geschwindigkeit nicht negativ beeinflusst. Natürlich kostet der Code, der zur Fehlerbehandlung ausgeführt wird (also z.B. das Anzeigen eines Hinweises) Zeit, aber die Fehlerbehandlung als solche nicht oder nur sehr minimal.
Ich möchte hier nicht diskutieren, wann eine Fehlerbehandlung mit Try...Catch...Finally Sinn macht und wann nicht, denn das würde den Rahmen dieses Miniartikels ziemlich sprengen. Aber das Laufzeitverhalten ist jedenfalls kein Argument gegen diese Art der Fehlerbehandlung.
