Try...Finally and performance

Try...Finally and performance

• Nexus_019

  if there is no catch then an exception will be thrown to the user - the catch is there to "catch" or pickup any exceptions, and handle it in your way, which is thrown within the try block

  finally is there to do things, such as dispose objects or whatever or making finalizations on the particular operation that has just been executed in that try block.

   

  
  
  

• Dan.G

  Honestly I think the whole discussion of EH performance is irrelevant. Think about it for a second. Would you rather have an app that runs blindly fast but crashes periodically with a simple "sorry" dialog from Windows or slightly slower with a meaningful message (hopefully) I'd lean toward the slightly slower version.

  However for the most part this isn't an issue. The CLR team went to great lengths from what I understand to optimize the EH framework in .NET. The bad thing about EH in languages like C++ is that the overhead (even when an exception doesn't occur) is high. In .NET however there is virtually no overhead when an exception is not thrown. I believe it simply pushes a special exception token (perhaps 1 per catch block) onto the stack that it would use to unwind the stack in case of an exception. Of course pushing something onto the stack is negligble in performance. So using try-catch and try-finally have no overhead. In fact creating an exception object itself has no more overhead than the creation of the object (which is the same for any other object you create). The only time you take a hit in performance is when you actually throw the exception. In this case performance will die a horrible death but honestly at that point it doesn't matter. Remember exceptions are for exceptional cases and not the norm so users normally wouldn't ever see the performance drop. I think the performance is even worse than C++ because I believe the exception walking code has to walk the stack twice (although only until it finds a catch block the first time I believe). I didn't write the code so I'm basing my comments on the available documentation and comments from the CLR team.

  Now your original question really was about the try-finally and try-catch-finally blocks. Eliminating the try-catch portion (as discussed in the preceding text) leaves the finally block. The performance of this code is the same whether you have try-catch-finally or simply try-finally. The net effect is a jump to the finally block to execute the code prior to leaving the context of the try block. Thus the overhead is simply a jump and the contents of the finally block.

  In general I would recommend that you liberally use try-finally blocks (with catch as needed) whenever you need to ensure that a specific block of code must be executed even in the face of exceptions. The only way to get the semantically equivalent code would be:

  try
  {
  ...
  } catch (Exception e)
  {
  exceptVar = e;
  };
  
  //Do any code that normally runs in a finally block
  ...
  
  //Throw exception again
  if (exceptVar != null)
  throw exceptVar;

  The try-finally block is much simpler and easier to read. In general the rules for code optimization say to optimize the code after you've evaluated the performance. The 80/20 rule applies here. If the worst performing code you have lies in a try-finally block then your code must really be optimized. In general you'll find that the performance is irrelevant when compared to all the temporary objects you are allocating and the strings you are creating or perhaps the numerous function calls you are making inside a loop. Thus in a nutshell unless you are calling this code in a tight loop or something then assume the block is efficient in normal cases.

  Michael Taylor - 3/31/06

  
  

• BloomyMB

  well i do understand but the performance I guess would be like this:

  if you have a general Exception in the catch block, then it will be slow/expensive as it has to find the correct exception to show to you for example. if you give it the specific exception then performance should be better and almost the same without the catch block.

  I really dont know how to explain this as its an unusual one but if you give it the specific exception to catch, perfomance will not be degraded.

  
  
  

• Goswinus

  There will be no difference in performance in my opinion.
  Throwing exceptions is expensive, but catching is not (off course, it depends what you'll do in the catch clause).
  When you have no catch, the exception is just bubbled up in the stack until a catch is encountered, but performance-wise, there'll be no significant difference.
  
  
  

• Souhail

  when the errorpotential code didn't throw an exception the ex variable is declared but no object is created !

  I think the difference is so minimal that you can't measure it. ( just an entry in a stack or a chek at the end of the try code).

  You can analyze the intermediate language ILDASM or you can measure the time in a loop or with a profiler to be shure about it.

  
  

• Kelly Stich

  when the errorpotential code didn't throw an exception. I believe the only different is that you need to create an instance of Exception object (ex), which will not be used.

  However, when the errorpotential code throw an exception, the one without the catch block will cause the program to halt(unless the exception is being handled by the code that call it). In contrast, the code with the catch block will catch whatever exception it is. For both of them, the code in the finally block will be executed.

  I think you should only consider the performance when the errorpotential code have a very low probabillity to throw an exception. Since if the code throw an exception, one will halt the program and one will not, and it is obvious that it is good to use the catch block.

  hope it helps,

  Ivan Wong

  
  

• Sajid Saeed

  I didn't ask for an explanation of how try..catch..finally works. That I do know. My question was about performance.
  
  
• Try...Finally and performance