> On 3 Jan 2022, at 16:10, Sérgio Martins wrote:
>
> On 2022-01-03 13:40, Lars Knoll wrote:
>> (...)
>> One other possible solution to improve compile times is the hack we
>> used 15 years ago in KDE, where we grouped many .cpp files into one
>> compilation unit. There’s however a balance neede
On Monday, 3 January 2022 12:10:04 -03 Sérgio Martins via Development wrote:
> It does make incremental builds slower, as then you need to recompile
> the entire amalgamation. For this reason I don't think
> it's a silver bullet.
It's not. Unless we're careful with the code we write, merging two .
On 2022-01-03 13:40, Lars Knoll wrote:
(...)
One other possible solution to improve compile times is the hack we
used 15 years ago in KDE, where we grouped many .cpp files into one
compilation unit. There’s however a balance needed here, as it reduces
the efficiency of -j, but maybe compiling 4-8
+1
Richard
On 20 Dec 2021, at 16:35, Tor Arne Vestbø
mailto:tor.arne.ves...@qt.io>> wrote:
Hello all,
I’d like to nominate Morten Sørvig as maintainer of high-DPI in the Qt Project
[1].
Morten has been instrumental in the development of Qt’s high-DPI support, and
has been the de-factor main
On 2022-01-03 08:43, Marc Mutz wrote:
Hi,
The Qt Creator folks have noted that compilation of Qt projects
against Qt 6.2 is sometimes almost twice as slow as it was in 5.15:
https://bugreports.qt.io/browse/QTBUG-97601
While we have some ideas where this may come from (including more std
headers
On Monday, 3 January 2022 10:40:42 -03 Lars Knoll wrote:
> One other possible solution to improve compile times is the hack we used 15
> years ago in KDE, where we grouped many .cpp files into one compilation
> unit. There’s however a balance needed here, as it reduces the efficiency
> of -j, but m
On Monday, 3 January 2022 11:05:25 -03 Philippe wrote:
> > The change to C++17 makes a huge difference too, regardless of PCH. That
> > #include in qglobal.h adds up to 300 ms in each build without
> > PCH, and a considerable amount with it too. And it gets worse with C++20
> > and ranges.
> I did
> The change to C++17 makes a huge difference too, regardless of PCH. That
> #include in qglobal.h adds up to 300 ms in each build without
> PCH,
> and a considerable amount with it too. And it gets worse with C++20 and
> ranges.
I did not notice any sensitive change when switching to C++20 (
On 3 Jan 2022, at 14:21, Thiago Macieira
mailto:thiago.macie...@intel.com>> wrote:
On Monday, 3 January 2022 05:43:53 -03 Marc Mutz wrote:
Hi,
The Qt Creator folks have noted that compilation of Qt projects against Qt
6.2 is sometimes almost twice as slow as it was in 5.15:
https://bugreports.
On Monday, 3 January 2022 08:09:39 -03 Ulf Hermann wrote:
> d, We used to build at least Qt itself with PCH by default. Why did we
> change the default?
I don't know about you, but I disabled PCH when I started using icecream for
distributed compiling about 5 years ago. It's incompatible with PCH
On Monday, 3 January 2022 05:43:53 -03 Marc Mutz wrote:
> Hi,
>
> The Qt Creator folks have noted that compilation of Qt projects against Qt
> 6.2 is sometimes almost twice as slow as it was in 5.15:
> https://bugreports.qt.io/browse/QTBUG-97601
>
> While we have some ideas where this may come fr
a) do we care
I care.
b) what metrics should we use to define success?
I don't care whether it uses PCH or not. It should do the fastest thing
by default. So, my metric is "time it takes to build " on my
machine. My favorite project is qtdeclarative, but I also build other
things.
c, Wh
Hi,
The Qt Creator folks have noted that compilation of Qt projects against Qt 6.2
is sometimes almost twice as slow as it was in 5.15:
https://bugreports.qt.io/browse/QTBUG-97601
While we have some ideas where this may come from (including more std headers,
qmetatype compile-time typename con
13 matches
Mail list logo
