Avoid exception throwing in performance-sensitive code
1–10 of 243 posts
Re: Avoid exception throwing in performance-sensitive code
#2Re: Avoid exception throwing in performance-sensitive code
#3I'm completely ignorant of the subject, but most surprising to me in his example was that the compiler didn't optimize away the inefficiency. Is there something about exception handling that makes it not get taken into account during optimization?
Re: Avoid exception throwing in performance-sensitive code
#4I'm completely ignorant of the subject, but most surprising to me in his example was that the compiler didn't optimize away the inefficiency. Is there something about exception handling that makes it not get taken into account during optimization?
Re: Avoid exception throwing in performance-sensitive code
#5I'm completely ignorant of the subject, but most surprising to me in his example was that the compiler didn't optimize away the inefficiency. Is there something about exception handling that makes it not get taken into account during optimization?
Re: Avoid exception throwing in performance-sensitive code
#6In most cases, when you don't control what you expect, exceptions are not great. In a constrained embedded system or a trading system, they can be amazing.
Re: Avoid exception throwing in performance-sensitive code
#7I'm completely ignorant of the subject, but most surprising to me in his example was that the compiler didn't optimize away the inefficiency. Is there something about exception handling that makes it not get taken into account during optimization?
Re: Avoid exception throwing in performance-sensitive code
#8When a new RuntimeException is thrown half the time, the example runs about 650 times slower when compared to a function which adds up the integers without using exceptions. If I define an exception subclass which doesn't fill in the stack trace, then it runs about 10 times slower. If I throw a singleton exception instance, then the performance is identical.
The reason why the performance is identical is because HotSpot inlined the code and converted the immediate throw-catch into a simple goto. It wasn't smart enough to see that the stack trace wasn't needed, nor was it smart enough to see that allocating new instances wasn't needed either. I had to make those transformations manually.
Re: Avoid exception throwing in performance-sensitive code
#9I'm completely ignorant of the subject, but most surprising to me in his example was that the compiler didn't optimize away the inefficiency. Is there something about exception handling that makes it not get taken into account during optimization?
Re: Avoid exception throwing in performance-sensitive code
#10Different languages have different exception handing optimizations. A Java version of the example can run very slow or very fast, depending on how clever you are. When a new RuntimeException is thrown half the time, the example runs about 650 times slower when compared to a function which adds up the integers without using exceptions. If I define an exception subclass which doesn't fill in the stack trace, then it ru…