List of Phobos functions that allocate memory?

[Dmitry Olshansky]

07-Feb-2014 20:49, Sean Kelly пишет:
> On Friday, 7 February 2014 at 16:41:00 UTC, Dmitry Olshansky wrote:
>>
>> Meh. If exceptions are such a liability we'd better make them (much)
>> faster.
>
> It's not stack unwinding speed that's an issue here though, but rather
> that for client-facing services, throwing an exception when an invalid
> request is received gives malicious clients an opportunity to hurt
> service performance by flooding it with invalid requests.

Why throwing a single exception is such a big problem? Surely even C's 
long_jump wasn't that expensive? *Maybe* we shouldn't re-construct  full 
stack trace on every throw?

> Improving the
> exception code specifically doesn't help here because the real issue is
> with GC collections.

Then the problem is that something so temporary as an exception is 
allocated on the GC heap in the first place? Let's go for something more 
sane and deprecate the current behavior, it's not like we are forever 
stuck with it.

>I'd say that the real fix is for such services to
> simply not throw in this case.  But the exception could always be
> recycled as well (since in this case you know that throwing will abort
> the transaction and so will always be immediately discarded).

Exceptions are convenient and they make life that much easier combined 
with ctors/dtors and scoped lifetime. And then we say **ck it - for busy 
services, just use good ol':
...
if (check42(...) == -1){ call_cleanup42(); return -1; }
...

And up the callstack we march. The moment code gets non-trivial there 
come exceptions and RAII to save the day, I don't see how busy REST 
services are unlike anything else.

> I'm not
> convinced that there's any need for a language change here to support
> scoped exceptions.  That seems a bit like killing the ant with a
> steamroller.

Well I'm not convinced we should accept that exceptions are many times 
slower then error codes (with checks on every function that may fail + 
propagating up the stack).

-- 
Dmitry Olshansky