Faster Virtual Method Dispatch

Craig Black cblack at ara.com
Tue Apr 25 09:08:25 PDT 2006


"Sean Kelly" <sean at f4.ca> wrote in message 
news:e2lgsh$5tf$1 at digitaldaemon.com...
> Craig Black wrote:
>> "Mike Capp" <mike.capp at gmail.com> wrote in message 
>> news:e2l4g1$2n5s$1 at digitaldaemon.com...
>>> In article <e2k12i$19bi$1 at digitaldaemon.com>, Walter Bright says...
>>>> 1) for every allocation, shared_ptr<> allocates an *extra* block of
>>>> memory to hold its accounting information. So you've got, out of the
>>>> box, twice as many allocations/deallocations happening.
>>> Not true for intrusive refcounting. (This isn't always feasible if 
>>> you're
>>> dealing with third-party classes, which is why shared_ptr isn't 
>>> intrusive, but
>>> if you _can_ use it it's very close to ideal.)
>>
>> What's intrusive refcounting?  Please use small words. My brain is almost 
>> full right now. :)
>
> Maintaining the reference count within the class being pointed to instead 
> of within the shared pointer code.
>
>>>> 2) for every copy of the shared_ptr<>, like passing one to a function,
>>>> returning one, etc., the reference count has to be incremented, then
>>>> decremented.
>>> Again, not true for intrusive refcounting. You can assign an intrusive
>>> smartpointer from a raw pointer or reference, so most of the time you 
>>> can use
>>> those to pass/return. Refcount twiddling is only needed when changing an
>>> "owning" pointer, plus the rare "safety" case where you have a raw 
>>> pointer but
>>> are calling code which might drop the last "real" owning ref.
>>>
>>>> And even with all that falderol, shared_ptr<> still can't do slicing,
>>>> which are an important efficiency improvement.
>>> Agreed, but couldn't you do something very similar with a simple ptr 
>>> class
>>> containing a pointer to the (refcounted) base string plus a couple of 
>>> range end
>>> indices? That's worked well for me in the past, but there may be 
>>> benefits of D
>>> slices that I'm missing.
>>
>> If you think this is doable, then you should write a C++ version of 
>> wordcount based on this principal.  If you can get comparable performance 
>> to the D version then you may be on to something.
>
> I'd meant to do this and never got around to it.  However, the wordcount 
> example is meant to compare performance using typical programming 
> techniques for each language, and writing your own specialized containers 
> isn't typical :-)

That's not the point.  It demonstrates that the same performance can be 
achieved without GC, and all the baggage that accompanies it.  So 
performance-wise it would be like having your cake and eating it too.  If 
this was possible, perhaps D could be streamlined to take advantage of this 
somehow.

-Craig 





More information about the Digitalmars-d mailing list