Know thy exceptions, part 2

(At the time of writing this, I have three comments on the previous article. That is the background to this post)

With a modified version of the below application, where I wrap the entire loop into a try-catch-statement instead of every iteration, and multiplying the number of iterations by 100 (for better statistical value), a debug-release generates the following:

VB.NET - Debug Build

  • With Try-Catch (100 iterations): 356433 ms
  • Without Try-Catch (100 iterations): 175644 ms
  • Diff: 180790 ms (49%)
VB.NET - Debug Build - Single Iteration, 3rd execution
  • With Try-Catch (100 iterations): 4703 ms
  • Without Try-Catch (100 iterations): 1750 ms
  • Diff: 2953 ms (37%)
VB.NET - Release Build
  • With Try-Catch (100 iterations): 248033 ms
  • Without Try-Catch (100 iterations): 175517 ms
  • Diff: 72516 ms (71%)
VB.NET - Release Build - Single Iteration, 3rd execution
  • With Try-Catch (100 iterations): 2516 ms
  • Without Try-Catch (100 iterations): 1750 ms
  • Diff: 766 ms (70%)

C# - Debug Build
- coming soon -

C# - Release Build
- coming soon -

Comments

Anders said…
I don't get quite the same numbers,
but I agree it looks like having a
Try-Catch does come with a performance-penalty.

I still think though, that if your functions are doing anything else that pure mathematics and/or variable assignment (such as DB-reads, file-manipulation, string-parsing or whatnot), the try-catch penalty is becoming a very very small part of the actual execution time of the function.

In practice it will become a negligible parameter in system development unless you are doing very computational-heavy work and/or for example real-time systems with extreme demands on execution/response time(in which case you probably won't use VB .NET on a windows platform anyhow).

As a side note, I tried making the iteration as an infinite loop that breaks when the iterator reaches a certain value, and that proved to be faster (66% exec time) than using the for loop without any error handling, thus being the fastest method of all AND fail-safe since I use an IF to check the only value that could possibly go wrong.

Can we draw any conclusions of this? I would think not, since the
code is still not representative of any real-life application that actually has a purpose.

Also, try-catch has the added benefit of catching the exceptions that we as programmers do NOT expect. Now, I know most of you probably make bug-free code from day one, but I'll still rely on my try-catch, thank you very much :D

/Anders (forever pragamatic and evil)
September 20, 2007 at 6:56 AM
Post a Comment

Popular posts from this blog

Auto Mapper and Record Types - will they blend?

Image
TL;DR: Yes, they will. Thank you for your time. 😄 Background At Redgate, engineers enjoy a great benefit in that we get are expected to spend 10% of our time to improve on our craft.  Having suffered this week with manually having to copy a bunch of properties from a domain object to its HTTP representation, I decided to spend this week's 10% time to see if I could answer the following questions: Can use AutoMapper to simplify mapping between two types?  Does it also allow me to map between a regular type and a record type? What about the other way around? Can I use this to reduce the maintenance burden in my product? Mapping between two types [automapper fundamentals] To started and get a basic mapping done, created a .NET 5 ASP.NET Web API project, added the below package references and configured automapper : < PackageReference Include ="AutoMapper" Version ="10.1.1" /> < PackageReference Include ="AutoMapper.Extensions.Microsoft.DependencyInj
Read more

Unit testing your Azure functions - part 2: Queues and Blobs

In our last installment , we discovered how to start unit testing our Azure Functions, looking at the HTTP Trigger (and evaulating the function's HTTP response). This time, we'll take a look at using the QueueTrigger, getting supporting data from table storage and outputting Blobs. Yup, I'm tossing you into the deep end! What are we trying to accomplish? This time, we will test a function that performs some arbitrary business logic on bank accounts. The function responds to a storage queue request, logs each command and ensures that each received command is executed exactly once. Almost like a real-world function, huh? ;-) In the function above, we are introduced to three types that we need to deal with in our unit tests - the IQueryable interface, IAsyncCollector and the CloudBlockBlob concrete type. IQueryable is easy enough to work with: Introducing the Testable Async Collector When I first started exploring this topic, I figured I could just use my favourit
Read more

Testing WCF services with user credentials and binary endpoints

Image
This article discusses the following error messages that you might receive from a WCF service An error occurred when verifying security for the message HTTP/1.1 415 Cannot process the message because the content type 'application/soap+xml;charset=UTF-8;action="..."' was not the expected type 'application/soap+msbin1' When doing analysis work on existing services, invoking them in a safe test environment is a handy way of getting an understanding of their operations, especially if the documentation has gone missing (or was never written). SoapUI is a tool that can be used to test WCF Services, but did you know that Visual Studio also comes with its own set of tools? Let's start with SoapUI, which is available from  http://www.soapui.org/ . Its operations are quite straight-forward; however, you might run into issues when trying to access services that are protected by user credentials, or when accessing services with binary endpoints. I
Read more