[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 21:36:54
[Download RAW message or body]

Dne èt 27. záøí 2001 17:27 Harri Porten napsal(a):
> On Mon, 17 Sep 2001, Lubos Lunak wrote:
> >  If you look in qvaluelist.h, you'll notice that all template classes
> > in this header file have their methods implemented in the class body,
> > which automatically makes them inline, even if they aren't explicitly
> > marked so. Some of the methods are quite large and this causes larger
> > executables. Moreover gcc won't inline some of them (compile with
> > -Winline to see),
>
> I didn't get any of these warnings. Strange. Did you have a lower limit
> set ?

 No, just -Winline. I don't even remember if I did the test with gcc-2.95, 
gcc-2.96 or gcc-3.0. Maybe the results differ for different gcc versions. And 
since there doesn't seem to be any other reason preventing inlining of the 
methods in QValueList< T > etc., the size of the code is usually the only 
factor.

>
> > because they are simply too large or for other reasons. Instead inlining
> > them, an out-of-line copy for them will be created, and such multiple
> > copies will cause conflicts. All large methods in templates should be
> > moved out of the class body, so they won't be treated as inline. Also,
> > they should be either enclosed by an #ifdef block, or they should be
> > in a separate source file. Since the definitions of non-inline template
> > methods won't be available, they won't be instantiated anywhere.
>
> I "outlined" two larger methods in QMap and looked at the results. An
> example program just containing a QMap<QString, QString> and lots of
> insert() statements got indeed smaller and compiled faster. Maybe this was
> just due to compiler optimization, though. libqt got slightly bigger. Is
> that because the compiler inserted an implementation of e.g. insert()
> although is wasn't used ? Recompiling Designer as a real world example
> unfortunately revealed nothing but a slight increase of a few kB in size.

 Are you sure those two qt versions were compiled with same compiler flags? 
QMap< QString, QString > is used in libqt, so "outlining" those methods 
shouldn't increase libqt's size, especially if insert() was used more than 
once in libqt. Maybe if it was used exactly once it could make it grow by few 
bytes.

>
> Any explanations or suggestions ?
>
> 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.
> According to a try of mine it seems to work with gcc 3.0.1, though.

 I don't see a reason why a compiler not doing automatic inlining of template 
member functions should break something. In this case moving the members 
explicitly out of the class shouldn't change anything. And changing inline 
functions to non-inline should be BC.


 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]