Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Avoid exception throwing in performance-sensitive code

lemire.me

Post reply on HN
Print view View original

21–30 of 243 posts

Re: Avoid exception throwing in performance-sensitive code

#21

Post by Gigachad »

kstenerud wrote: post #16

This post is poorly named. What it's saying is to avoid throwing exceptions for normal flow control, and just use them for exceptional cases (file not found, etc). Performance-sensitive code or not, exceptions for exceptional situations are not going to hinder the app's performance until the exceptional situation becomes common (unless your language does lots of exception setup work on the happy path - which most hav…

Seems like a language design flaw that this is slow. Imo Rust got this right by making "exceptions" nothing special, just a data type holding an error which can be processed just as fast as anything else.

Re: Avoid exception throwing in performance-sensitive code

#23

Post by junon »

bogwog wrote: post #13
pclmulqdq wrote: post #6

Exceptions are great for exceptional conditions in performance-sensitive code. They provide a mechanism to move your error-handling code far out of the hot path. If you are expecting an occasional exception, they are terrible, and the C way of returning an error code is the way to go. In most cases, when you don't control what you expect, exceptions are not great. In a constrained embedded system or a trading system,…

Why would error-handling code impact performance? Besides, exceptions in C++ are known to have negative impacts on overall performance even if you don't use them. (see: https://preshing.com/20110807/the-cost-of-enabling-exception... )

Code paging. If your hot code spans multiple pages, you run the risk of the CPU needing to perform page fetching to continue executing your code. If your exception handling code causes the hot path to exceed the page size, then you run the risk of cache misses which can cripple performance.

Rust has the #[cold] attribute for this exact reason - to mark functions or branches as 'cold', placing them into a separate section to reduce the hot path's code size.

Re: Avoid exception throwing in performance-sensitive code

#24

Post by fsckboy »

excepts were the only way in CLU to handle control flow. something like

    while read_character { 
        handle_character 
    } except_when end_of_file {
        return string
    }
and it did this primarily because it was typesafe: read_character always returned a character, and the "except" cases could return what they were declared to return. "except" was far from exceptional.

There's nothing ineffecient about that, it's meatly linked up at compile/load time, and exceptions that go up the stack simply unwind the stack just as returning values up the stack do.

What gets users confused is conflating this with the idea of hardware interrupts and system signals, external exceptional events that can occur at any time, interrupting the flow of control and needing registers (cpu state) to be saved so the process can be restored and continue when the interrupt is handled. (and which CLU handled through the same system) Such interrupts and signals do have a superficial resemblance to excepts that are unexceptional, and to not so unusual and recoverable errors like out-of-disk-space on a file write, which is only code you're going to write for an important high availability or headless system, or a nice fat rich word processor that people will sit in all day long.

I'm just explaining this all because when I read discussions like this I'm constantly thinking "but...but... did you think of...?"

Re: Avoid exception throwing in performance-sensitive code

#26

Post by polynomial »

Gigachad wrote: post #21
kstenerud wrote: post #16

This post is poorly named. What it's saying is to avoid throwing exceptions for normal flow control, and just use them for exceptional cases (file not found, etc). Performance-sensitive code or not, exceptions for exceptional situations are not going to hinder the app's performance until the exceptional situation becomes common (unless your language does lots of exception setup work on the happy path - which most hav…

Seems like a language design flaw that this is slow. Imo Rust got this right by making "exceptions" nothing special, just a data type holding an error which can be processed just as fast as anything else.

Which is not to suggest you should be using exceptions for flow control.

Re: Avoid exception throwing in performance-sensitive code

#28

Post by bhawks »

polynomial wrote: post #26
Gigachad wrote: post #21

Earlier quoted context omitted.

Seems like a language design flaw that this is slow. Imo Rust got this right by making "exceptions" nothing special, just a data type holding an error which can be processed just as fast as anything else.

Which is not to suggest you should be using exceptions for flow control.

Python's StopIteration has entered the chat.

Re: Avoid exception throwing in performance-sensitive code

#29

Post by nosianu »

Gigachad wrote: post #21
kstenerud wrote: post #16

This post is poorly named. What it's saying is to avoid throwing exceptions for normal flow control, and just use them for exceptional cases (file not found, etc). Performance-sensitive code or not, exceptions for exceptional situations are not going to hinder the app's performance until the exceptional situation becomes common (unless your language does lots of exception setup work on the happy path - which most hav…

Seems like a language design flaw that this is slow. Imo Rust got this right by making "exceptions" nothing special, just a data type holding an error which can be processed just as fast as anything else.

> Seems like a language design flaw that this is slow

I think stack traces take up much of the time, including converting it [1]. Without them it could probably be a lot faster. Also see hashmash's post.

But other than that, there is the logic issue, not using exceptions for normal flow control makes sense at least to me too independent of any performance questions.

[1] For a Java example: https://ionutbalosin.com/2018/06/getting-the-stack-trace-ver...

Re: Avoid exception throwing in performance-sensitive code

#30

Post by ajkjk »

AussieWog93 wrote: post #19

TIL that it's even possible to use exceptions instead of bog standard if statements. Would love to know why people would do this, though. Surely everyone masters if-else ssatements well before they even learn what a try-catch statement is!?

If/else statements don't bubble and exceptions do. The code samples in this example are clearly simple representations of the pattern, but the pattern is to call into a more complex function than `get_positive_value`.
Post reply on HN