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

List:       kde-core-devel
Subject:    Re: QT_NO_STL in KDE4
From:       David Faure <faure () kde ! org>
Date:       2006-09-13 14:56:05
Message-ID: 200609131656.09055.faure () kde ! org
[Download RAW message or body]

On Wednesday 13 September 2006 12:59, Dirk Mueller wrote:
> On Wednesday 13 September 2006 10:59, Lubos Lunak wrote:
> 
> > > Because kde3 did - that's the only reason so far.
> >  So we no longer care that it noticeably increases build times or it
> > doesn't do so anymore?
> 
> Just my own small little benchmark: 
> 
> $ make -j30 kdelibs r583758:
> real    9m2.265s
> user    7m58.346s
> sys     3m48.798s
> 
> $ make -j30 kdelibs r583758 -DQT_NO_STL:
> real    6m16.271s
> user    5m53.586s
> sys     2m49.827s

Wow that's a large difference if it's indeed only due to -DQT_NO_STL.
Surprising, for just a few typedefs....

But then the best solution would be to do like we always did with exceptions: disabled
by default but can be enabled where needed. Similarly we could re-add QT_NO_STL by
default but allow CMakeLists.txt files to use remove_definitions(-DQT_NO_STL).

> But anyway, building time is unimportant. The point of -DQT_NO_STL was that no 
> STL crap sneeks into our code, so that: 
> 
> $ du -sk b-with-stl/lib b-without-stl/lib
> 25826   b-with-stl/lib
> 25826   b-without-stl/lib
Strange line of argumentation; you are not proving that using stl algorithms instead
of hand-written code makes executables smaller or bigger, you are only saying that
we are not using them right now (so of course QT_NO_STL changes nothing).
You imply that with stl algorithms it would be worse, but this is no proof, it might well
be better when used properly.

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
[prev in list] [next in list] [prev in thread] [next in thread]