D pointers

[Koos Vriezen]

On Thursday 29 September 2005 13:49 Lars Knoll wrote:
> On Thursday 29 September 2005 11:01, Dirk Mueller wrote:
[..]
> > but other than that, inlined
> > accessors are still faster than non-inlined ones.
> 
> And except for very few cases it doesn't matter that your access is not 
> inlined. A typical GUI application is idle 99% of it's time. Things that have 
> to be fast are mostly startup, painting and processing of large amounts of 
> data.
[..]
> * You don't need to include thousands of header files; forward declarations 
> are usually enough. This also reduces dependencies and compile time.
[..]
> * 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.

Koos