D pointers

[George Staikos]

On Thursday 29 September 2005 07:49, Lars Knoll wrote:
> On Thursday 29 September 2005 11:01, Dirk Mueller wrote:
> > On Thursday 29 September 2005 10:06, Zack Rusin wrote:
> > > the other way around. Lars can tell you more about his futile attempts
> > > of optimizing this class (making it use lazy-parsing). Everything is
> > > inlined so we couldn't do anything.
> >
> > So the issue wasn't the missing d pointer. Yes, the d pointer would have
> > enforced to not write inline accessors, 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.

  In my KDE session right now, which "looks" like I am running KMail, 
Konqueror, and Konsole only, I have 26 k* applications running.  I guess that 
means 26% of the time my cpu is non-idle?  This is more significant.

   Also some applications do need to use >1% of cpu time, and if our libraries 
are inefficient, they become inappropriate for the needs of those apps.

> Inline methods in an API severly limit the possibilities you later on have
> to change/refactor (and thus improve) your implementation.

  I fully agree here.

> We moved everything into the d pointer for lots of reasons:
>
> * We allocate a d pointer anyway. Even if you could avoid it in a 4.0
> release by moving all members into the class itself you will most probably
> need the d pointer in a 4.1/4.2 release.

   Really?  It's a bit hard to believe that even a significant number (>10%) 
of classes need this, especially so soon.  I think you guys are better than 
that. :-)

> * You keep the public API clean and uncluttered. The header files remain
> very readable.

   It's an admirable goal, but it should never affect performance in any way.

> * You don't need to include thousands of header files; forward declarations
> are usually enough. This also reduces dependencies and compile time.

  Same as above.  Compiling longer on one or two development machines is cheap 
compared with 1,000,000 users needing more CPU at runtime.

> * Sometimes you use some variables in your class and you would like to
> replace them by something else in the next revision. You can only do that
> freely if the member is inside the d pointer.

   You and I worked out how to do this in KApplication without touching the 
d-pointer. :-)

> The good old rule that you shouldn't optimise without having measured also
> applies here. The gained flexibility by having the data structures hidden
> usually more than outweighs a loss of speed that is in most cases not even
> measurable.

  I have done such measurements in the past and found extra mallocs in classes 
to be major limiting factors.  Especially in script interpreters and 
applications that do real-time visualization.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/