List of Phobos functions that allocate memory?

[Jonathan M Davis]

On Saturday, February 08, 2014 21:21:40 Walter Bright wrote:
> On 2/8/2014 2:11 PM, Dmitry Olshansky wrote:
> > 09-Feb-2014 02:03, Walter Bright пишет:
> >> On 2/7/2014 9:06 AM, Dmitry Olshansky wrote:
> >>> Why throwing a single exception is such a big problem?
> >> 
> >> Because in order to unwind the stack, you need to find the information
> >> about the stack layout. This lookup is rather slow. You can make the
> >> lookup faster by compromising the function code generation, but this is
> >> considered an unacceptable tradeoff.
> > 
> > A special table lookup can't be slow compared to writing a dummy HTTP 500
> > response. Just saying. Yes, it's a tad slower then cmp + jz, I do
> > understand that.
> > 
> > Again I'm trying to say that framing stack unwinding as the culprit of
> > vibe.d crawling under bad requests is plain wrong, and that was the focal
> > point of the original argument.
> 
> I don't know how vibe.d works, but my point is using exception handling to
> implement normal control flow is bad design and it is going to be slow and
> the reason it is slow is because of the table lookup and unwinding cost,
> and that is not going to be fixed.

I wouldn't have considered throwing on an HTTP error to be "flow control." 
That's normal error handling, and throwing on HTTP errors is exactly what I 
would have done. It generally makes code a _lot_ cleaner that way, because you 
don't have to constantly check return codes for errors, and it's using 
exceptions for exactly what they're there for - reporting and handling errors.

You don't want to use exceptions for stuff other than error reporting, and you 
don't want to use them in situations where the error case is the frequent 
case, but that shouldn't be the case for HTTP.

Exceptions _will_ be slower than other code paths, and you don't want them to 
be the normal code path. Nothing is going to make exceptions as fast as the 
normal code paths either. However, D's exceptions are painfully slow - far 
slower than is reasonable - whether that's because of allocating the exception 
or unwinding the stack or creating the string for the stack trace or whatever 
is a matter for investigation, and I'm not about to claim that I know where 
the bottlenecks are.

Fortunately, it looks like Adam Ruppe has found some ways to speed up 
exceptions:

https://github.com/D-Programming-Language/druntime/pull/717

And there may be other improvements that we can implement as well. I agree 
that there's a limit to how much we can speed up exceptions, but right now, at 
minimum, we're getting creamed by Java in terms of speed:

https://d.puremagic.com/issues/show_bug.cgi?id=9584

- Jonathan M Davis