Faster Virtual Method Dispatch

[kris]

Craig Black wrote:
> "BCS" <BCS_member at pathlink.com> wrote in message 
> news:e2isuc$2jmd$1 at digitaldaemon.com...
> 
>>In article <e2inmo$2bjp$1 at digitaldaemon.com>, Craig Black says...
>>
>>>"Dan" <Dan_member at pathlink.com> wrote in message
>>>news:e2im9o$29gi$1 at digitaldaemon.com...
>>>
>>>>Ultimately though, I think the GC causes the highest level of 
>>>>performance
>>>>troubles on the benchmarks.  I love it to death though and wish someone
>>>>would
>>>>get their hands dirty making it smaller and sexier.
>>>
>>>Or (truly) optional. :)  The notion that the GC is optional in D is really
>>>misleading.  Everything uses it.  While you could certainly make it faster
>>>at the expense of more complexity, I don't think that GC that scans the
>>>stack testing for non-null pointers will ever provide the performance of 
>>>C's
>>>malloc and free.  GC is simply performing much more work.  I have heard 
>>>many
>>>arguments to the contrary, but I still don't see how it is possible that 
>>>GC
>>>could compete with malloc and free.
>>>
>>
>>
>>A bad GC will definitely make for bad performance. And any GC will be 
>>slower
>>than an optimum malloc/free solution. However (and I'm still undecided on 
>>this
>>one) I think the argument is that in any non trivial project, manually 
>>freeing
>>all of the memory without any memory leaks or axing something to soon 
>>would
>>require more overhead than using GC. The trade-off is not in the freeing 
>>time
>>but in the can-I-free-this check.
> 
> 
> I have heard similar.  "The code required to manually free everything 
> outweighs the overhead of automatic GC."  Unless you are doing something 
> rediculous in your code when freeing heap objects, this statement is false. 
> Manual freeing does not require gobs of code or eat up lots of processor 
> cycles.  Typically it involves testing a pointer to see if it is null, 
> calling free() if it is not, and then setting it to null.  How could this 
> ever be slower than scanning the entire stack for non-null pointers?  GC is 
> simply doing way more work.  IMO this statement is simply obsurd.
> 
> The benefit of GC is not performance, but convenience.  If you want the 
> convenience of not having to free memory manually then use GC.  However if 
> you want performance, use malloc and free (new and delete).
> 
> That is why GC should be completely optional, not just on a per class basis. 
> If I want to completely eliminate GC from my application, I should be able 
> to do so and still be able to make use of any standard library capabilities.
> 
> -Craig 
> 
> 


The nice thing about D, as a language, is that it supports both 
approaches. The bad thing, for your needs, is that phobos is tightly 
bound to the GC. My particular gripes are with the GC activity caused 
via utf conversions, std.string and so on. There's a surprising, perhaps 
troublesome, amount of GC activity generated from within phobos itself. 
This is one of the reasons alternative libraries exist.