[dmd-internals] Memory Leak
David Held
dmd at wyntrmute.com
Sun Nov 11 16:28:24 PST 2012
On 11/11/2012 2:33 PM, Walter Bright wrote:
> [...]
> I've thought about using smart pointers for the CTFE stuff. I think
> that would resolve it.
>
> I'm a little concerned that using smart pointers in general would
> cause slowdowns.
Well, if you have the choice between compiling small programs quickly,
or compiling large programs at all, which do you think is the better
choice for dmd? And really, I think the performance hit is much smaller
than you fear. With decent inlining, dereference can be as cheap as
native pointers, and reference counting only starts to get expensive if
you need to support multi-threading. Even then, by using raw pointers to
indicate non-owning usage, you can avoid the vast majority of reference
count changes. And then, to make a fair comparison, you have to judge
the result against 100% manual memory management (free() tends to be
more expensive than malloc()). I think you will find that smart
pointers stack up pretty well (although I would not advocate a
general-purpose one like shared_ptr<>...that's a bit heavyweight for dmd).
> Another refactoring I'd like to see happen in dmd is that some of its
> data structures become copy-on-write, as many, many problems have been
> caused by changing things that someone else assumed wouldn't be changed.
And that job would be made a lot easier if all data were private to
begin with. ;) Again, a lot of these changes could be detected with
some asserts at strategic locations (although, asserts cannot catch all
mutations, obviously, which is why private data goes further).
When you say "some data structures", do you mean the Dsymbol hierarchy?
That seems to be a pretty major core of the front-end. It would be great
if that were immutable...I see a lot of methods which could probably be
made const (in fact, 90% of the interface could be made const with no
other change, I think).
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20121111/f35216ec/attachment-0001.html>
More information about the dmd-internals
mailing list