On 04/24/2011 08:08 PM, Iain Buclaw wrote:
== Quote from Timon Gehr (timon.g...@gmx.ch)'s article
Andrei Alexandrescu wrote:
I am sorry, you simply have no case - each and every argument you put
forth has no strength or is just wrong. We could spend time on debating
each, but I suspect that would do little toward convincing you of what
is after all a simple fact, but one with many subtle facets. It might
not a good use of our time to further engage in a diatribe on this. The
delete keyword will go, as will class-specific new and delete.
Andrei
Is it correct that the current D GC implementation puts delete'd allocations
into
a freelist (or bucket) to be reused when 'new' is invoked again?
I don't know. If it does, an additional level of freelists only hurts.
Ok, lets stop. Custom allocators and delete should probably be removed from D:
Some of my facts:
* freelist is faster if most allocation and deallocation concentrates on only
one
class. (see attachment) I think this is also the reason it increases DMDs speed.
Token and Scope are quite obvious bottlenecks..
* such bottlenecks will most of the time only be detected when development is
almost finished. (Almost never for library code, so I don't get why STL uses
custom allocators at all.)
* premature optimization is evil (see STL custom allocators)
* late optimization: it is easy if there are custom allocators. In C++ it is
even
trivial. Nice design. Still no clue why STL is abusing it.
* that form of custom allocators does not play nicely with Ds Garbage collector
though, because it changes the semantics of 'new', ergo builtin custom
allocators
should probably indeed be removed from D.
* this makes this form of optimization painful in D without custom allocators.
This is what I was instinctively scared about. Fact is: it is also painful with
them, because you don't get the 'delete's for free as in C++. I was somewhat
inconsiderate on this.
* it is possible that hinting the GC is only about twice as bad (again, see
attachment).
And some notes:
* the fact that you think all my points were worthless or wrong implies that you
either did not read all of them or have not considered them yourself when making
your decision. I think that is scary.
I find it nuts that someone considers blaming/shunning language features just to
mask bad runtime semantics they refuse to fix - but maybe it's just my ignorance
on the subject that professes that view.
I'd appreciate if you provided more detail on that. Far as I can tell
the problem is with the feature under discussion, not some alleged
unwillingness to do work.
Andrei
