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

List:       kde-commits
Subject:    Re: KDE/kdelibs
From:       Frans Englich <frans.englich () telia ! com>
Date:       2005-09-26 19:47:08
Message-ID: 200509261947.08445.frans.englich () telia ! com
[Download RAW message or body]

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.

I think worrying about performance is a programmer decease. I constantly hear 
this "let's chop of our legs, and In Theory it should save a nano second." 
Premature optimization is evil.

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?

So, I'm surely not against optimization. I just need proof, and stuff in touch 
with reality before I go breaking other stuff which is important, and that is 
for sure developer flexibility, API design and BC.


Cheers,

		Frans

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