Faster Virtual Method Dispatch

BCS BCS_member at pathlink.com
Mon Apr 24 09:04:28 PDT 2006


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.





More information about the Digitalmars-d mailing list