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

List:       kde-core-devel
Subject:    Re: Reducing the number of conflicts in libraries
From:       Lubos Lunak <l.lunak () sh ! cvut ! cz>
Date:       2001-09-27 22:05:46
[Download RAW message or body]

Dne èt 27. záøí 2001 19:16 Harri Porten napsal(a):
> On Thu, 27 Sep 2001, Guillaume Laurent wrote:
> > As far as I know, Lubos is right. I'm looking at qvaluelist.h and I'm
> > pretty sure you'd get a very significant benefit by moving the
> > implementations out of the body.
>
> I do believe in this, too. In theory. I'd prefer to see some numbers.
>
> I just recompiled Qt and Designer with -O3 (gcc 3.0.1) and got at a saving
> of 5 kB in the application opposing a plus of ~1K in the library (insert()
> and insertSingle() methods changed). I might have to convert and compile
> more code to get clearer results.

 4 KB saved for 2 methods changed to non-inline doesn't seem to be a bad 
result. There are many more methods worth such change.

>
> > > I was told that gcc < 3.0 doesn't do any automatic inlining of template
> > > member functions at all so one has to be very carefull with a redesign.
> >
> > As some point with Gtk-- we tried to inline most of our code, since it
> > was essentially single-line methods. The library size almost doubled.
> > That was with g++ 2.9 I think.
>
> I should take a closer look at the suggest pragmas directives.

 See 'info:/gcc/Deprecated Features'. They seem to be deprecated for template 
instantiation.

 Actually, now it looks like that all we should do now about these things is 
to sit and wait (well, besides making the template members non-inline). I 
mailed Jakub Jelinek and he said he'll probably have a testing implementation 
of the more aggresive linking (which will discard duplicates of template 
instances in all libs) ready in a month, so we can forget all this explicit 
templates etc. madness, the only thing needed would be the 'nm' check 
described in http://gcc.gnu.org/ml/gcc/2001-09/msg00421.html . Maybe even the 
'at_least_one_noninline_virtual_method_in_every_class' changes you did could 
be reverted if they're not needed for something else. I however don't know 
what the situation on non-GNU systems is.

>
> > Another thing is, inlining in templates can easily become a performance
> > killer because due to the expansion of templates within templates etc...
> > you can get fully expanded methods which won't fit in your CPU cache
> > anymore.
>
> Yes. But there are so many factors playing a role that is almost
> impossible to judge from a plain look.
>
> Harri.


 Lubos Lunak
-- 
 llunak@suse.cz ; l.lunak@kde.org
 http://dforce.sh.cvut.cz/~seli

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