vibe.d & exception performance

Marc Schütz" <schuetzm at gmx.net> Marc Schütz" <schuetzm at gmx.net>
Sun Feb 9 08:07:51 PST 2014


On Sunday, 9 February 2014 at 13:04:20 UTC, Dicebot wrote:
> You seem to forget that actually writing data to socket takes 
> time and this time is longer than one needed for most simple 
> stack unwinding. Fun fact - even if you copy rendering code to 
> static exception example it will still be ~5-10% faster because 
> it will cancel pending async socket output and terminate fiber 
> early.

Oh, I'm not surprised that it can be faster than the 
non-exception version, after all, it does less work.

What troubles me is the large speedup if you use both a 
statically allocated exception, and don't generate a stack trace. 
Neither of them alone makes that much of a difference. I would 
have expected the combined performance gain to be the sum of both 
for themselves, more or less.

But the difference actual difference is so much larger. Where 
does it come from? It might mean that there is some costly 
operation that both `new` and `toString()` perform. Or it might 
actually be a bug, and when fixed, would have worse performance. 
It seems almost too good to be true...

>
> But yes, those results match my earlier observations - 
> pre-allocated exceptions with no stack trace generation are of 
> fast enough to not be a concern. Impact of both of those 
> factors is huge enough to provide DoS vector.

Yes, if it is really safe to use, vibe.d should introduce a 
"production" mode, where it neither outputs nor logs stack traces 
by default. That's a good idea anyway, to keep internal 
information from leaking out to a potential attacker.


More information about the Digitalmars-d mailing list