On Monday, 10 February 2014 at 01:16:27 UTC, Jonathan M Davis
wrote:
On Sunday, February 09, 2014 21:57:13 Dmitry Olshansky wrote:
Split out of "List of Phobos functions that allocate memory?".
To reiterate, here is some critique, compiled:
1. Exceptions are class instances, hence (by default) are
allocated on
GC heap. This is wrong default, GC is no place for temporaries.
The more I think about it, the less I'm convinced that this is
a big deal.
Sure, it would be nice if they were malloc-ed and
reference-counted so that
they'd go away immediately after they were used and didn't risk
triggering a
collection, but for exceptions to work right, they need
inheritance, so they
have to be classes, and since exceptions are generally rare,
having the extra
overhead of the memory allocation usually isn't a big deal, and
if it triggers
a collection or sticks around for a little while after it's
used (because no
collection gets run), most code won't care.
The code that really cares is code that's having to throw
exceptions more
frequently and/or in situations where those exceptions really
need to be fast.
Personally, I've only run into that in unit tests, and I don't
think that the
GC has much do with that slowness (and Adam Ruppe's current
work on that seems
to support that it's not the GC that's an issue). So, if the
stack traces (or
whatever it is that's making them slow) can be fixed to be
faster, then as far
as unit tests go, I would consider the matter taken care of and
the fact that
the GC is used for exceptions to be a non-issue.
The place where this becomes an issue then is code that needs
exceptions to be
really fast (e.g. it sounds like vibe.d falls in that camp).
And in that case,
it doesn't really matter whether the exceptions are allocated
on the GC heap
or malloc's heap. If memory allocation is slowing them down,
then they need to
get rid of the memory allocation entirely, in which case, doing
something like
having a pool of pre-allocated exception objects to reuse would
make a lot
more sense. And in that case, it would probably be better if
they weren't on
the GC heap, but the exception-throwing code wouldn't really
care either way.
That would be up to the pool. The same goes if only a single,
static exception
were used. It might be marginally better if it weren't on the
GC heap, because
it would avoid being scanned, but in those cases where you want
speed, you
_want_ long lifetimes for the exceptions, not short lifetimes
like you're
suggesting, because you want to reuse the exceptions in order
to avoid needing
to allocate new ones. The only way that short lifetimes would
work is if we
weren't dealing with classes and the exceptions were on the
stack, but that
negates our ability to have an exception hierarchy - which is
critical to how
exceptions work.
And if some code is getting exceptions frequently enough that
the memory
allocation is the bottleneck, then maybe exceptions aren't the
best choice
either. I agree that exceptions need to be much, much faster
than they are,
but they're still intended for the error case, which should be
relatively
infrequent.
2. Stack trace is constructed on throw. User pays no matter if
the trace
is needed or not. This is in the works, thankfully.
Yes, which should be a significant improvement and likely a
much larger gain
than any memory allocation issues.
3. Turns out message is expected to be a string, formatted
apriori:
https://github.com/D-Programming-Language/druntime/blob/master/src/object_.d
#L1306 Formatting a string in such setting inevitably
allocates and it
happens at the throw site, even if nobody is using that
message down the
line. At least one can override toString...
Ideally, creating the string that toString returns would be put
off until
toString is called (particularly since that includes the stack
trace), but I
would hope that creating the message string to pass to the
exception's
constructor would be cheap enough (particularly in light of the
fact that the
exception is heap-allocated anyway) that it wouldn't be a big
deal. So, if we
can find a way to make this more efficient without getting
messy, that's
great, but I wouldn't expect that to be a bottleneck just so
long as the
actual string that the message gets put into for toString to
return (which
then includes the file and line and stacktrace and whatnot)
isn't created
until toString is called.
- Jonathan M Davis
All that wouldn't be a problem if D had ARC for everything,
including Exception`s.
