Faster Virtual Method Dispatch
Craig Black
cblack at ara.com
Mon Apr 24 11:29:03 PDT 2006
"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
More information about the Digitalmars-d
mailing list