The Performance Cost Of Throwing Exceptions (or Custom Exceptions) In ColdFusion
A couple months back, I read Ben Nadel's blog on The Performance Cost Of Throwing Exceptions In ColdFusion. It made me curious how my custom validation exception would perform. Using Ben's code, I ran a base test on my computer to have an apples to apples comparison.
The ColdFusion cfthrow Test
Throw Exception: false
Throw Exception: false
I expected my custom exception to run slower than coldFusion's exception. My java code just inherits RuntimeException, and then I cfthrow object="javaObject". I'm curious what cfthrow message="me" does that it is twice as slow.
The ColdFusion cfthrow Test
Throw Exception: false
- Results: 63
- Results: 63
- Results: 47
- Results: 62
- Results: 62
- Results: 890
- Results: 718
- Results: 672
- Results: 672
- Results: 1,219
Throw Exception: false
- Results: 62
- Results: 62
- Results: 63
- Results: 62
- Results: 63
- Results: 422
- Results: 438
- Results: 406
- Results: 422
- Results: 391
I expected my custom exception to run slower than coldFusion's exception. My java code just inherits RuntimeException, and then I cfthrow object="javaObject". I'm curious what cfthrow message="me" does that it is twice as slow.
Definitely very intereseting. I'm sure there is some low-level reasoning behind this, but it is beyond me :)
ReplyDeleteThat is interesting. As an aside, how are you liking the exception-based validation? I just took a look at your linked post; I've never thought of doing that way. Has it been working nicely?
ReplyDeleteIt works out great! Instead of creating a errorDTO for every beanDTO, I now have a dynamic errorDTO that works in the same way. And my views for displaying the errors are much cleaner too, since my if logic is encapsulated in the errorException. I am still not sure why my inherited exception class is faster than coldfusion's exception. But even if it was a little slower, being able to have less code is a great advantage!
ReplyDelete