List of Phobos functions that allocate memory?

[Adam Wilson]

On Fri, 07 Feb 2014 10:54:37 -0800, Sean Kelly <sean at invisibleduck.org>  
wrote:

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

Technically, there is no reason that the current GC can't be made  
incremental, insofar as incremental means collecting only what is required  
complete the allocation.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator