On 11/11/2012 4:28 PM, David Held wrote:
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?
Good question. But also consider that we're transitioning to 64 bit compilers,
where consuming a lot of memory may not be relevant, since most of that memory
will be "dead".
And really, I think the performance hit is much smaller than you fear. With
decent inlining, dereference can be as cheap as native pointers,
Not quite true, remember the destructor code has to be inserted and accounted
for in all cases. This can add more than just a pointer decrement & test.
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.
I know about the potential for raw pointers to have all sorts of bugs from
incorrect usage. C++ has no way to protect against that.
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).
One of the versions with embedded counters would be far more suitable.
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?
No, I mean the Expression one. The Type hierarchy is already copy on write, and
works well.
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).
Yes, adding const in would probably be an easy and effective change. Too bad C++
has no purity :-(
_______________________________________________
dmd-internals mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals
