C# Real Time Try Catch

views:

587

answers:

+5 Q:

C# Real Time Try Catch

I'd like a response from someone who actually does real-time programming in C# or who really understands the language internals.

I know that exceptions should not be used to handle normal processing, but only to detect error conditions. There is plenty of discussion on that topic.

I'd like to know if there is any run time slow-down from simply having a try/catch block in place (which never catches an exception unless the program will have to end anyway). The try/catch block is inside a function which must be called repeatedly. I suspect there is only minimal cost.

Can the cost be quantified in terms of CPU cycles, or other tasks (same cost as a floating point multiplication), or another way?

We use Microsoft C#.Net 3.5 under windows XP.

+9 A:

.NET exceptions have a very, very low overhead cost unless they are thrown. Having a try/catch block in place will have a very minimal performance impact. I have found nearly no impact, even in very fast, tight loops, to having exception handling in place.

However, exceptions in .NET are VERY expensive when they're thrown. They tend to be much high-impact on performance if you throw them than many other languages. This is due to the full stack information gleaned when the exception is created, etc.

This is the opposite behavior to some other languages, such as python, where exception handling has a higher cost, but throwing is actually fairly performant.

However, if you are concerned, I would suggest you profile your routine, and test it yourself. This has been my experience after quite a bit of performance profiling. There is no substitution for measuring in your own codebase.

Reed Copsey 2009-08-28 15:49:37

Actually, a stack trace does not occur until you access the StackTrace property, or if the exception passes a process boundary (i.e. remoting/wcf/etc.) Creating an exception is also very low cost, as construction only sets a few properties. A moderate cost is incurred by the throw process setting StackCrawlMarks that facilitate a stack crawl if and when the StackTrace is requested...but in .NET 2.0, the trace does not occur every throw unless you actually access it.

jrista 2009-08-28 15:57:34

Yes - I was actually referring to the stack marking mechanism, but my answer wasn't clear. This does, though, in my profiling, have a fairly significant overhead (this is assuming perf. critical systems, though). Rico Mariani has a good blog post explaining why, but for me, the issue was the extra cache misses and page faults: http://blogs.msdn.com/ricom/archive/2006/09/25/771142.aspx

Reed Copsey 2009-08-28 16:02:39

Thanks for that info. Unfortunately we do not have the tools to profile our code... we just have to follow best practices.

Mark T 2009-08-28 16:04:08

If you're writing real-time software, you NEED TO GET A PROFILER. There is absolutely no substitution for measuring. You can write code following all of the rules, and the thing that you think will be performant will be a bottleneck - it happens all the time. There are many profilers available for .NET, including some reasonable free profiling tools.

Reed Copsey 2009-08-28 16:06:28

For example: http://code.google.com/p/slimtune/

Reed Copsey 2009-08-28 16:09:13

+1 A:

Good discussion, with metrics, of performance implications of try catch here.

http://stackoverflow.com/questions/1308432/do-try-catch-blocks-hurt-performance-when-exceptions-are-not-thrown

Gratzy 2009-08-28 15:57:29

ansaurus

tags:

views:

answers:

C# Real Time Try Catch

related questions