D pointers

[Lars Knoll]

On Friday 30 September 2005 15:36, George Staikos wrote:
> 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.

But 90% of KDEs classes are not such that they would suffer from this at all. 
There are very few classes that are used tight inner loops where the function 
call overhead for a getter would really matter.

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

Why not? If you add new functionality to a class you sometimes need additional 
data members. And you don't want us to stop adding functionality do you? ;-)

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

See the post from Lubos where he measured KURL performance. The worst he could 
get it to perform was 2.5 percent slower. Now, this is one of the few classes 
where one would think it could make a difference (as opposed to things as 
KListView of KLabel), and even here it's nothing which is noticable in an 
application.

You could probably gain a lot more than 2.5% by spending a little time and 
optimising the performance of KURL (which you can do if not everything is 
inline).

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

This is not 100% true. Longer compiles affect our rate of progress as a 
project. If a developer has to wait double the time to get KDE compiled he 
can do less work. And not everyone has a large icecream farm available.

And as I already said, the performance difference is in 99.9% of the cases not 
noticable. The remaining 0.1% should be optimised/inlined. And my stand is 
that the flexibility gained from not inlining will later on help you fix 
performance bottlenecks (that you might have been unable to fix otherwise).

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

Some things are possible, but only as long as you don't have an inline 
accessor, but as you also know it's really hacky and nothing one wants to do.

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

Sure (see also the blog zack mentioned in his mail). But you're talking about 
some very special things. None of the classes in kdelibs (with the exception 
of some kjs and khtml internals) are used that way.

Lars