D pointers

[Lubos Lunak]

On Friday 30 of September 2005 15:57, Koos Vriezen wrote:
> On Thursday 29 September 2005 13:49 Lars Knoll wrote:
> > On Thursday 29 September 2005 11:01, Dirk Mueller wrote:
...
> > * You can move all private methods into the d-pointer. Since private
> > classes don't get exported you reduce the number of exported symbols
> > which in turn reduces library size and startup time.
>
> Above points do not address the argument IMO. Inline accessors don't need
> extra include files. Also this has nothing to do with putting private
> functions in d-pointer. Actually having inline accessors removes a symbol
> (hidden inlines) and as such speeds up application loading (w/ g++ > 4.0.0)
>
> On kdelibs 3.3.2 debian/testing:
>  nm -C -D /usr/lib/libkdecore.so.4.2.0 |grep " W " |wc -l
>  1736
>  nm -C -D /usr/lib/libkdecore.so.4.2.0 |grep " T " |wc -l
>  4223
> On kdelibs 3.5 branch compiled w/ visibility:
>  nm -C -D $KDEDIR/lib/libkdecore.so.4.2.0 |grep " W " |wc -l
>  137
>  nm -C -D $KDEDIR/lib/libkdecore.so.4.2.0 |grep " T " |wc -l
>  4138
>
> So putting everyting back to " T " adds here about 1600 symbols only for
> libkdecore and that will slowdown startup for sure.

 You need to add also grep -v "<.*>" there, to get rid of all the template 
instantiations, which have nothing to do with this. That brings it down to 
about 500. That's quite a lot to be sure, but it's enough for me to bet on 
the fact that all of those are out-of-line copies of virtual inline methods 
and similar cases where gcc can't decide on a single place to put them. Which 
means you haven't measured anything useful, at least not for this case.

 Doing grep ").*{" *.h | wc -l in kdecore, which is the best way I can think 
of, says there are about 350 inlines in kdecore. And actually the dynamic 
linker is not that bad these days, from LD_DEBUG=statistics about 0,13s (2GHz 
machine) is spent on that for KWrite. So with 500MHz machine turning all 
those inlines into non-inlines will increase the cost from 0,6s to ... 
uhm ... some maths, guesses and being pessimistic ... 0,8s . Big deal.  And 
this is the guy often working on optimizations saying this.

 My opinion, in short, is. We need d-pointers. Moving all members from the 
class to the private class doesn't cause any important performance impact, 
except (possibly) for heavily used classes. Which are usually rather simple 
and can be in the worst case fixed by having KFixedFoo class. Inlines can 
prevent modifications of a class, and again, there shouldn't be any important 
performance impact, except for some classes. IOW IMHO we can decide without 
paying that much attention to performance impact.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/