Faster Virtual Method Dispatch

[Craig Black]

"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. :)

>>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.

-Craig