Some timing regarding ADL..

[Milian Wolff]

David Nolden, 26.11.2010:
> 2010/11/26 Milian Wolff <mail at milianw.de>:
> > While I agree, doing more profilling would maybe be good. I will try to
> > do such testing in the future, at least on KDevplatform/KDevelop or
> > similar sized projects.
> > 
> > But As Andreas said, it stayed in the branch for weeks without *anyone*
> > being interested in it. Only a few users told me that they really like
> > this branch, that it works fine for them. So I trusted the, merged it
> > and saw that it was working quite nice. Then a few days later I noticed
> > the slowdown during code completion which was fixed ASAP by Ciprian, so
> > nothing wrong there.
> > 
> > And I'd rather have new contributors doing good work (even if it's not
> > perfect) then no new things at all. And it's not like I merged this stuff
> > blindly, I did skim through the changes and didn't see anything obvious.
> > I mean hell, I don't even know what ADL is nor when it's applicable and
> > when not, I wouldn't have seen how to improve this case. We simply need
> > people like you in our project, who know Cpp really well *and* know
> > their way around the code base. And really, if it's just 8h of work,
> > what's the problem? I spent much more on some much less important
> > features...
> > 
> > Anyways, this doesn't help at all and I don't see why I should defend
> > myself here. Who codes decides, and you sadly disappear for weeks
> > sometimes and left me no choice but to try to improve KDevelop in the
> > best way possible that I can.
> 
> This wasn't ment as an attack against you. I think you're doing a good
> job of tracking the merge requests, and I thank you for that, as I
> don't have that much time. I'm also not talking about "doing new
> stuff", but about "changing existing stuff".
> 
> I don't expect anyone except me to directly see the performance
> problems on such a patch, I have a feeling for the expenses of each
> duchain operation, after all I've written most of them. However, I
> think I have verbalized my concerns regarding this patch.
> 
> The thing is, when I sometimes _have_ time, then I want to do
> something constructive (I have a lot on my list which is more
> important for productivity than ADL, for example incremental parsing).
> I don't want to be _forced_ to spend hours and hours just to get the
> application back into a (to me) acceptable state. This is frustrating,
> first because I don't get to the things I really want to do, and
> second because it gives me the feeling that the stuff would fall apart
> if I wouldn't monitor it closely.
> 
> So I simply wish for some more conservative changing behavior
> regarding existing and well-working code. I don't care if there appear
> new "unfinished" features in the master, but the existing stuff should
> keep working right. If you don't fully understand the patch (btw. I
> also don't fully understand some of the C++ support patches, the stuff
> is simply too complex), then at least do some really thorough testing.
> 
> In other words: Please don't do "David will fix it" commits. ;-)

I apologize if this came around like this, it was by no means my intention. 
Trust me, if I'd have been hit as hard as you with this performance problems, 
I'd have spent time on it myself, I just didn't use KDevelop much this week.

So lets keep this in mind and continue as is, next time you can hit me with a 
stick if I merge something which is too slow for you and give me a hint on how 
to reproduce, then I'll try to fix it myself.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20101126/568743ea/attachment.sig>