List of Phobos functions that allocate memory?

[Sean Kelly]

On Friday, 7 February 2014 at 17:06:36 UTC, Dmitry Olshansky
wrote:
> 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?

That can be turned off at run time by clearing the traceHandler.
But yeah, it's the allocations that are a problem in this case,
not the unwinding.  And specifically, that flooding with bad
requests effectively generates tons of garbage (an allocation for
the exception plus another for the trace data) thus triggering
frequent stop-the-world collections.


> 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 sure you can see how a service is different from a desktop
application, right?  In the latter case, there's only one user
and he's interested in having his application perform well.
Outside of a QA lab you won't find desktop app. users
deliberately trying to break their app.  Services are exactly the
opposite.  It's not an exaggeration when I say that the services
I work on are under attack from botnets 24/7.  This is a use case
that must be considered as a first order of business or the
entire service suffers.


>> 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).

Exception-oriented code is typically faster for the success case
because all that return code checking can be removed.  But the
tradeoff is that it's slower in the failure case because stack
unwinding is simply slower than checking an error code.  But
again, the issue here isn't the cost of stack unwinding, it's
that thousands of exceptions thrown per second generates a lot of
garbage, and garbage collection in D is currently fairly slow
compared to, say, Java.  If we could get an incremental GC for D
I probably wouldn't even care, but I think that's impossible.