D pointers

[Lubos Lunak]

Dne pá 30. září 2005 18:27 Alexander Neundorf napsal(a):
> Hi,
>
> On Friday 30 September 2005 17:46, Lubos Lunak wrote:
> ...
>
> > think of, says there are about 350 inlines in kdecore. And actually the
> > dynamic linker is not that bad these days, from LD_DEBUG=statistics about
> > 0,13s (2GHz machine) is spent on that for KWrite. So with 500MHz machine
> > turning all those inlines into non-inlines will increase the cost from
> > 0,6s to ... uhm ... some maths, guesses and being pessimistic ... 0,8s .
> > Big deal.  And this is the guy often working on optimizations saying
> > this.
>
> To be honest, 0.13 s on a 2 GHz machine is a lot of time. Everything which
> takes longer than 0.1 or maybe 0.2 seconds to start feels slow. If this
> time is already spent in the linker there is no chance a KDE application
> could ever startup fast.
> Also an increase from 0.6 s to 0.8 s would be a lot of time, it would be 33
> % more.

- It's (quite likely overestimated) 0,2s difference on a machine which is 
low-end by today's standards and old crap by the time KDE4 is ready. And 
please don't try those "33% more" statistics tricks on me, no matter how many 
percent it's still 0,2s on a machine that's bloody slow (and I happen to be 
using such one right at the moment actually).

- All these calls are done via PLT if I get things right, which means they can 
be lazily bound and therefore shouldn't affect startup performance that much.

- Prelink should take care of this.

- It's not those hypothetical 0,2s vs nothing, it's hypothetical 0,2s vs 
hypothetical inability to fix/improve our libraries.

> When I was trying to optimize konsole startup, initially it was 
> about 320 ms on a 200 MHz box. I was able to get the time down to something
> like 180 ms, i.e. 140 ms seconds saved. These 100 ms really made a
> difference, it felt noticeably faster.

 Are you sure all those numbers aren't missing one trailing zero? I seriously 
doubt you can recognize 100ms difference in app startup, that's even far 
below your reaction time (http://www.steriley.com/speed/).

> malloc()'s are expensive. In code which gets executed very often they 
> really should be avoided. Widget creation is no such case. (Ok, when the
> application starts all widgets are created at once, so then this should be
> fast too). Working with QStrings is such a case. And I never suspected that
> KURL would be a "slow" class, but as I learned it seems KURL might be also
> such a case.
>
> There are some (more or less ugly) ways to get away without malloc(), like
> using pools or adding some (fixed) space for future extensions. In
> performance critical cases such things might be considered.

 Malloc is not _that_ bad. Using our own malloc used to make a difference 
because the glibc one used awfully slow locking. If you check the fastest 
path (i.e. for allocation sizes of about <=64bytes) in the current malloc 
it's actually only a couple of instructions. Time spent in malloc is not 
going to dominate unless done in very performance critical code, which is not 
creation of most of our classes.

 And in reply to Koos:
> > deal.  And this is the guy often working on optimizations saying this.

> That is not a very convincing argument :-)

 So who would have to say that then? Do you expect to have a vision of The 
Great Konqi (praised be his name) in your dreams saying "yes, performance 
doesn't really matter in this d-pointers and inlines discussion, especially 
when considering the benefits/cost ratio" :) ? I'm not saying it's definitely 
so, but to my best knowledge it is, and I have something to confirm my belief 
which you can try out yourself. If somebody still thinks performance is an 
issue here, ok, we can discuss that, but so far this's been mostly vague 
arguments, so unless somebody has something worth discussion, I consider this 
performacne issue closed.

 Can we now discuss other issues of the problem, if there are any?

-- 
 Lubos Lunak
 KDE Developer
 l.lunak at kde.org     l.lunak at suse.cz