Re: [Interest] Compile Speed Question regarding MOC

2014-02-19 Thread Till Oliver Knoll
Am 19.02.2014 um 05:10 schrieb Constantin Makshin cmaks...@gmail.com:

 Look at the problem from the other side:
 1) separate moc_*.cpp has to be compiled only during full [re]builds
 or when the corresponding class' header file is changed;
 2) when moc_*.cpp is #include-d into the implementation .cpp file,
 they are both compiled at every change.

With regards to 1): A ful rebuild takes the time it takes, no matter what. You 
can speed that up things as others have suggested (#include the mocced files, 
AUTOMOC), but that's that.

As full rebuilds are (usually) done offline on some build/integration/test 
server, time does not really matter, unless the build is not ready the next 
morning ;)


IMHO what is more important is to speed-up incremental builds 2), as those 
times are most annoying for every developer.

So here are my general tips to avoid /dependencies/:

In headers, #include only what is really necessary!

- Use forward declarations as much as possible

E.g. when you pass along a QString as parameter, do it by reference instead 
of by value, if possible (even though we know the later is cheap due to copy 
on write semantics of most Qt container classes).

class QString; // forward declaration

class Foo {
public:
  Foo(const QString theString);
  ...
}

Do that especially with your own classes (because you are unlikely to change 
the QString header anyway ;))


- Use the private *d idiom

 (there is a name for it which I don't recall at the moment)

/That/ saves you a lot of dependencies!

E.g.

class BarPrivate: // again, forward declare, avoid dependency!

class Bar {
public:
  ...
private:
  BarPrivate *d;
}

Then you declare and instantiate/destroy (new/delete) that member class in the 
*.cpp file (only). Now you can start messing around with BarPrivate and 
add/remove members as you wish - the consumers of your Bar class will never 
notice and won't need to recompile!

Off course there are some downsides, too: if you have many many instances of 
Bar, you end up with many many (small) dynamic allocations, possibly leading to 
memory fragmentation.

Also if you want to inherit from Bar and at the same time want to have direct 
access to its (now protected) members, there is some extra effort to do with 
that d pointer pattern - see Qt code and its use of helper macros ;)


- Does it /need/ to be an is-a relation?

Or wouldn't a has-a relation not fit the problem better anyway?

This is one of the classic design questions ;)

In my general experience people just inherit too much (and hence introduce 
dependencies on the base class, instead of hiding that dependency with a 
has-a relationship, e.g. implemented with the d-pointer pattern above).



When you follow those advises and really need to change a header in some lower 
library class then the impact will be kept to a minimum :)


Cheers,
  Oliver
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Compile Speed Question regarding MOC

2014-02-19 Thread Yves Bailly
Le 19/02/2014 09:21, Till Oliver Knoll a écrit :
 - Use the private *d idiom
   (there is a name for it which I don't recall at the moment)

The pimpl (pointer to implementation) idiom, or Cheshire cat.

http://en.wikipedia.org/wiki/Pimpl
see also 
http://herbsutter.com/2013/12/31/gotw-7b-solution-minimizing-compile-time-dependencies-part-2/

:-)

-- 
  /- Yves Bailly - Software developer   -\
  \- Sescoi RD  - http://www.sescoi.fr -/
The possible is done. The impossible is being done. For miracles,
thanks to allow a little delay.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Compile Speed Question regarding MOC

2014-02-19 Thread Till Oliver Knoll
Am 19.02.2014 um 09:28 schrieb Yves Bailly yves.bai...@sescoi.fr:

 Le 19/02/2014 09:21, Till Oliver Knoll a écrit :
 - Use the private *d idiom
  (there is a name for it which I don't recall at the moment)
 
 The pimpl (pointer to implementation) idiom, or Cheshire cat.

Yes, the cat it was ;)

Thanks,
  Oliver
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Compile Speed Question regarding MOC

2014-02-19 Thread Gisle Vanem
Till Oliver Knoll till.oliver.kn...@gmail.com wrote:

 With regards to 1): A ful rebuild takes the time it takes, no matter what. 
 You can speed that up things as others have suggested (#include the mocced 
 files,
 AUTOMOC), but that's that.

What about using pre-compiled headers (pch) with MSVC? I imagine the
total time for a full rebuild with MSVC (using PCH and multiple .cc-files in 
one go) is much less than a partial build using e.g. gcc/MingW. I'm not sure
how good PCH in gcc has become.

I ask since I've not tried it. I'm not sure it's possible to use MSVC's PCH 
with Qt.

--gv
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Compile Speed Question regarding MOC

2014-02-19 Thread Till Oliver Knoll
Am 19.02.2014 um 09:51 schrieb Gisle Vanem gva...@yahoo.no:

 ...
 
 I ask since I've not tried it. I'm not sure it's possible to use MSVC's PCH 
 with Qt.

Ah yes, precompiled headers will also help speed-up (subsequent) full rebuilds.

That is supported by qmake, depending on the compiler/platform support for them:

  http://qt-project.org/doc/qt-5/qmake-precompiledheaders.html


I have never used them though, as my headers are either not stable enough ;), 
or too small anyway to give any noticeable performance (I assume).


Cheers,
  Oliver___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Compile Speed Question regarding MOC

2014-02-19 Thread Konstantin Tokarev


19.02.2014, 12:52, Gisle Vanem gva...@yahoo.no:
 Till Oliver Knoll till.oliver.kn...@gmail.com wrote:

  With regards to 1): A ful rebuild takes the time it takes, no matter what.
  You can speed that up things as others have suggested (#include the mocced 
 files,
  AUTOMOC), but that's that.

 What about using pre-compiled headers (pch) with MSVC? I imagine the
 total time for a full rebuild with MSVC (using PCH and multiple .cc-files in
 one go) is much less than a partial build using e.g. gcc/MingW. I'm not sure
 how good PCH in gcc has become.

 I ask since I've not tried it. I'm not sure it's possible to use MSVC's PCH 
 with Qt.


Moreover, PCH's have some positive effect with gcc and clang too.


Regards,
Konstantin
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Compile Speed Question regarding MOC

2014-02-19 Thread Till Oliver Knoll
Am 19.02.14 09:21, schrieb Till Oliver Knoll:
 ...
 When you follow those advises and really need to change a header in some 
 lower library class then the impact will be kept to a minimum :)

Just to get an idea from my pet project which mostly follows the
advices I gave:

Number of header files (including generated ones):

$ find . -name *.h | wc -l
72

About half of them are mocced:

$ find . -name moc_*.cpp | wc -l
30


With roughly 20'000 number of lines (headers and sources, including
comments and generated code) I get:

$ time make -j4

real0m16.953s
user0m58.294s
sys 0m4.159s


That is about 17 seconds for a full rebuild, including
generating/parsing all moc/ui files. On an Mid 2011 iMac with 8 GB RAM
running at 3.4 GHz Intel Core i7.


Cheers, Oliver
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Compile Speed Question regarding MOC

2014-02-19 Thread andre
On Wed, Feb 19, 2014 at 09:21:01AM +0100, Till Oliver Knoll wrote:
 Am 19.02.2014 um 05:10 schrieb Constantin Makshin cmaks...@gmail.com:
 
  Look at the problem from the other side:
  1) separate moc_*.cpp has to be compiled only during full [re]builds
  or when the corresponding class' header file is changed;
  2) when moc_*.cpp is #include-d into the implementation .cpp file,
  they are both compiled at every change.
 
 With regards to 1): A ful rebuild takes the time it takes, no matter what.
 You can speed that up things as others have suggested
 #include the mocced files, AUTOMOC), but that's that.

That's not the full truth. Each compilation unit comes with an overhead of
included system headers. A while ago that easily was 50k+ LOC for a
standard C++ translation unit, and less than 20k LOC for a typical pure
Qt TU. Luckily, the std side improved a bit, on the other hand some clever
soul decided to pull half of std:: into qmetatype.h on Mar 28, 2013,
effectively killing any competetive advantage pure Qt had in this area.

At the end of the day, the lines pulled in from the system (Qt or not)
still will outweigh your own code's contribution to a typical TU by a
magnitude, so total compilation time is in first approximation roughly
proportional to the number of TUs.

 [...]
 IMHO what is more important is to speed-up incremental builds 2), as
 those times are most annoying for every developer.
 
 So here are my general tips to avoid /dependencies/:
 
 In headers, #include only what is really necessary!

 
 - Use forward declarations as much as possible

True.

 - Use the private *d idiom

True at least for public headers. If the header isn't used widely,
this has to be weighed.

  (there is a name for it which I don't recall at the moment)

Pimpl?
 
 - Does it /need/ to be an is-a relation?
 
 Or wouldn't a has-a relation not fit the problem better anyway?
 
 This is one of the classic design questions ;)

True. Has a typically decouples better than is a. So, when in
doubt there should be no doubt what to use...
 
 In my general experience people just inherit too much (and hence
 introduce dependencies on the base class, instead of hiding that
 dependency with a has-a relationship, e.g. implemented with the
 d-pointer pattern above).

Absolutely.

Andre'
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


[Interest] Compile Speed Question regarding MOC

2014-02-18 Thread Michael Jackson
I have what seems to be an obvious question/answer but the subtleties may not 
be what I think they are. We have a project with about 500 files most of which 
inherit from QObject or QWidget which means they all have moc run on them. 
Currently I have each moc created file compiled as a separate object which 
means for every class I have I am really compiling 2 files (.cpp and 
moc.cxx). The compile times are starting to get up there a bit and I was 
wondering what others do at this point? Do you simply do the #include 
moc_MyClass.cxx in the .cpp file of MyClass? Does that really help speed up 
the compile process? Before I go updating all of our source files I just wanted 
to get a quick sanity check for this course of action from the Qt community.

Thanks for any advice.
Mike Jackson

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Compile Speed Question regarding MOC

2014-02-18 Thread Stephen Kelly
On Tuesday, February 18, 2014 17:04:54 Michael Jackson wrote:
 I have what seems to be an obvious question/answer but the subtleties may
 not be what I think they are. We have a project with about 500 files most
 of which inherit from QObject or QWidget which means they all have moc run
 on them. Currently I have each moc created file compiled as a separate
 object which means for every class I have I am really compiling 2 files
 (.cpp and moc.cxx). The compile times are starting to get up there a
 bit and I was wondering what others do at this point? Do you simply do the
 #include moc_MyClass.cxx in the .cpp file of MyClass? Does that really
 help speed up the compile process? Before I go updating all of our source
 files I just wanted to get a quick sanity check for this course of action
 from the Qt community.
 

If you use CMake and AUTOMOC, the 'loose' moc files will be included in a 
single file and compiled together (one per target).

Thanks,

-- 
Stephen Kelly stephen.ke...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions

signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Compile Speed Question regarding MOC

2014-02-18 Thread Tony Rietwyk
Mike wrote:

 Sent: Wednesday, 19 February 2014 9:05 AM
 
 I have what seems to be an obvious question/answer but the subtleties may
 not be what I think they are. We have a project with about 500 files most
of
 which inherit from QObject or QWidget which means they all have moc run
 on them. Currently I have each moc created file compiled as a separate
 object which means for every class I have I am really compiling 2 files
(.cpp
 and moc.cxx). The compile times are starting to get up there a bit
and
 I was wondering what others do at this point? Do you simply do the
#include
 moc_MyClass.cxx in the .cpp file of MyClass? Does that really help speed
 up the compile process? Before I go updating all of our source files I
just
 wanted to get a quick sanity check for this course of action from the Qt
 community.
 
 Thanks for any advice.
 Mike Jackson

I had the same problem, and use qmake to generate VS, XCode and Make
projects.  I noticed the Qt sources include the moc in each .cpp.   I
changed my code to do the same and it works well.   The qmake utility
recognises this and does not create a separate compile step for them.   Of
course the real solution is to get a faster machine.  

Regards, 

Tony


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Compile Speed Question regarding MOC

2014-02-18 Thread Michael Jackson

On Feb 18, 2014, at 7:48 PM, Tony Rietwyk t...@rightsoft.com.au wrote:

 Mike wrote:
 
 Sent: Wednesday, 19 February 2014 9:05 AM
 
 I have what seems to be an obvious question/answer but the subtleties may
 not be what I think they are. We have a project with about 500 files most
 of
 which inherit from QObject or QWidget which means they all have moc run
 on them. Currently I have each moc created file compiled as a separate
 object which means for every class I have I am really compiling 2 files
 (.cpp
 and moc.cxx). The compile times are starting to get up there a bit
 and
 I was wondering what others do at this point? Do you simply do the
 #include
 moc_MyClass.cxx in the .cpp file of MyClass? Does that really help speed
 up the compile process? Before I go updating all of our source files I
 just
 wanted to get a quick sanity check for this course of action from the Qt
 community.
 
 Thanks for any advice.
 Mike Jackson
 
 I had the same problem, and use qmake to generate VS, XCode and Make
 projects.  I noticed the Qt sources include the moc in each .cpp.   I
 changed my code to do the same and it works well.   The qmake utility
 recognises this and does not create a separate compile step for them.   Of
 course the real solution is to get a faster machine.  
 
 Regards, 
 
 Tony

Thanks everyone for the feedback. I just wanted to make sure I was not going to 
fall into some esoteric trap or something. I use CMake for my projects so I 
went ahead and enabled the AUTOMOC feature and it seems to be build just find 
now. Again, thanks for the help.

Mike Jackson

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Compile Speed Question regarding MOC

2014-02-18 Thread Constantin Makshin
Look at the problem from the other side:
1) separate moc_*.cpp has to be compiled only during full [re]builds
or when the corresponding class' header file is changed;
2) when moc_*.cpp is #include-d into the implementation .cpp file,
they are both compiled at every change.

I think it's pretty obvious that (1) is better for debug/incremental
builds because changes in the implementation .cpp file don't affect the
moc-generated one, saving compilation time, while (2) is better for
release/full builds as the compiler has to do much less work parsing
headers #include-d by the class header file. And since debug builds are
done much more often than release ones, I personally prefer keeping
implementation and moc-generated code in separate files.

On 02/19/2014 02:04 AM, Michael Jackson wrote:
 I have what seems to be an obvious question/answer but the subtleties may not 
 be what I think they are. We have a project with about 500 files most of 
 which inherit from QObject or QWidget which means they all have moc run on 
 them. Currently I have each moc created file compiled as a separate object 
 which means for every class I have I am really compiling 2 files (.cpp and 
 moc.cxx). The compile times are starting to get up there a bit and I 
 was wondering what others do at this point? Do you simply do the #include 
 moc_MyClass.cxx in the .cpp file of MyClass? Does that really help speed up 
 the compile process? Before I go updating all of our source files I just 
 wanted to get a quick sanity check for this course of action from the Qt 
 community.
 
 Thanks for any advice.
 Mike Jackson



signature.asc
Description: OpenPGP digital signature
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest