On Thu, 20 Feb 2014 21:05:29 GMT, Dicebot wrote:
On Thu, 20 Feb 2014 19:08:46 +0100, Sönke Ludwig wrote:
I definitely think that 2) is the absolute minimum that has to be done
(it would probably even be enough to resolve symbols for the stack trace
lazily). And probably when that is done, there isn't even a real problem
anymore (the 404 case should still be changed).No, it won't be enough, I have made some quick tests with hacked changed druntime. You will never ever be able to use exceptions efficiently if those are allocated (especially if it is GC allocation that can trigger collection). It may not be notable if normal processing code also allocates regularly but than it does not make any sense to speak about performance at all.
We use exeptions in similar way in some Sociomantic code but both conditions are strictly conformed (custom runtime + always reuse instances). It is natural desire because of convenience but exceptions were never designed for throwing performance (and D spec explicitly warns about it) so you can't get it without making some sacrifices and/or restrictions. Prohibiting storing exception instances (or doing fiber switch inside catch) is smallest such sacrifice that can work.
An alternative pattern is to use version exceptions to be immutable in release code (with no fancy custom formatting) and costly allocated in debug mode.
In practice most applications don't really care though same as they don't pay much attention to allocations in user code.
Sooo... what is the way to go here ?
I recently build the first component at work using vibe.d (a REST api) that performs quite nice as long as everything goes fine. but totally poos itself when requests reach an invalid url, that burns the CPU because of this issue..