[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: KDE/kdelibs
From:       George Staikos <staikos () kde ! org>
Date:       2005-09-26 21:41:46
Message-ID: 200509261741.46199.staikos () kde ! org
[Download RAW message or body]

On Monday 26 September 2005 15:47, Frans Englich wrote:
> On Monday 26 September 2005 19:02, Shaheed wrote:
> > On Sunday 25 September 2005 22:02, André Wöbbeking wrote:
> > > > But on the part about private structs, can I safely assume it is NOT
> > > > the norm to start moving member variables into private structs just
> > > > for compilation performance? In fact, I would expect that at each
> > > > opportunity to break BC, we would try to flatten the private structs
> > > > out where convenient.
> > >
> > > The main reason FOR d-pointers is BC. So I don't think that they are
> > > removed. That d-pointers also make the interface cleaner, reduce
> > > dependencies and improve compile time are a nice addons.
> >
> > I am not suggesting the removal of the d-pointers; I understand the role
> > they play in preserving BC.
> >
> > What I am checking/suggesting is that the intent should be to flatten the
> > private structures they point to into the parent structure at convenient
> > (non-BC preserving) times even though that might imply an increase in
> > compile time, because that is surely to be preferred to the run time
> > overhead of two allocations/structures.
> >
> > Otherwise some might think it a good idea to move *all* private members
> > to the private structure pointed to by the d-pointer.
>
> And my view is the exact opposite of yours, to /not/ remove d-pointers but
> namely add more d-pointers.

   You are also confused.  Shaheed is saying to do this:

KDE 3.x:
class Foo {
  private:
    FooPrivate *d;
};

class FooPrivate {
  public:
    int bar;
};

KDE 4.0:
class Foo {
  private:
    FooPrivate *d;
    int bar;
};


   He's not saying to remove the private class.  He's saying to flatten the 
private class by removing its contents and roll them back into the parent 
class.  Then remove the extra malloc from the constructor until it's needed 
again.

> I think worrying about performance is a programmer decease. I constantly

  This is a horrible thing to hear.

> hear this "let's chop of our legs, and In Theory it should save a nano
> second." Premature optimization is evil.

  This isn't premature.  This is systematic and has to be dealt with now.  We 
can't change it later.

> This time, it's about that even though our API development is inconsistent,
> happens fragmented, and that BC is a PITA to have as developer partner, one
> of the few mechanism we have to make our lives easier should be removed in
> the name of speed. Where is the _proof_ for what is _claimed_ to be a
> relevant gain? Is there profiling numbers for typical codepaths run
> with/without d-pointerification?

  Malloc is well known to be a major performance issue.  I've had factor of 
100 speedups in code (a script interpreter I wrote) simply by reducing 
implicit malloc calls.

> So, I'm surely not against optimization. I just need proof, and stuff in

  You can easily prove it to yourself.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/
[prev in list] [next in list] [prev in thread] [next in thread]