On Tue, Apr 29, 2025 at 9:48 AM Paul M. Jones <pmjo...@pmjones.io> wrote: > > > > > On Apr 27, 2025, at 07:26, Niels Dossche <dossche.ni...@gmail.com> wrote: > > > > Regarding performance however, rather than introducing yet another > > completely new concept to do almost the same thing, why not try to improve > > exception performance instead? > > > > I just opened a PR that makes instantiating exceptions much much faster, > > and this is only after like 15 mins of work. I'm sure there's even more to > > gain. > > I mean, squeeze out gains where you can where the effort:reward ratio is > good, but the following is a naive but representative result on an MacBook M3 > Pro: > > ``` > return false 100000 times = 0.075289011001587 > throw exception 100000 times = 0.11530804634094 > ``` > > Do we consider a difference of 0.075/100000s vs 0.115/100000s that big a deal > when compared to (e.g.) establishing a database connection?
The first part, the 0.075 vs 0.115... yeah, we care. That's 50% slower. But the thing is, the math with exceptions is kind of knowable because one of the key aspects of its cost is walking the call stack. How deep is the call stack going to be when a given library throws an exception? You don't really know. I work for an observability company on a profiler, so I regularly see customer call stacks. It is incredibly common to see much deeper call stacks, especially any framework with a middleware concept. I can't share a lot more detail without customer permission, but we do have a blog post about a real-world situation for one of our customers which had 85-ish frames deep when they were throwing exceptions: https://www.datadoghq.com/blog/php-exception-profiling/. tl;dr For this customer, throwing exceptions accounted for about 23% of the total CPU time. So yeah, we _do_ care about the performance of exceptions. Granted, code for this customer was bit of an unusual situation, but it still matters even today. It definitely matters if people are going to start throwing exceptions more frequently for less-exceptional errors.
