List of Phobos functions that allocate memory?

[Dmitry Olshansky]

07-Feb-2014 22:54, Sean Kelly пишет:
> On Friday, 7 February 2014 at 17:06:36 UTC, Dmitry Olshansky
> wrote:
>>> 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.

Which should be somehow prominently advertised for release builds. Last 
time I checked not making it null made exceptions ridiculously slow.

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

So again - the problem is allocations on GC heap. Then let's please not 
worry about tiny gains of avoiding stack unwind, that is well understood.

And I see no reason for allocating exceptions on GC (and none presented 
so far). The main use case of exception is to consume exception on catch 
or forward it down the line. Storing a reference to an exception 
elsewhere is rare case. I could see the whole situation with exceptions 
in D as
"we copied this shit from Java, no idea why"

Java at least does go to great lengths to make them fast
(by caching them behind the scenes and whatnot).

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

Aye, in fact I haven't written much in the way of desktop apps.

> 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 bet some sanity checks on the level of protocol handling is more then 
enough.
Yeah these might be faster then unwinding due to shear volume of bad 
data, but it's a fraction of code albeit a critical fraction.

I was thinking about the service logic on top of that.

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

Duly noted. Just stating the obvious - in the majority of cases we talk 
about 1 unwind vs 10s of checks. The difference isn't THAT big anyway, 
the only advantage of codes checking is being able to fail faster on 
some _early_ bad condition.

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

Let's stop bashing GC here. This part of design of exceptions in D is 
just backwards (penalizes usual case) - time to fix it?



-- 
Dmitry Olshansky