Friday Facts #115 - The power switch

[CodAv]

As others stated, three minutes isn't that bad for a complex C++ project, especially in Visual Studio. In our largest project, I actually managed to reduce compile time on a quad core I7 from 25 to about 5 minutes just by optimizing the includes, especially not including Boost where it's not absolutely needed, and using forward declarations wherever possible. Just Boost pulled in about 1500 additional headers in each compilation unit. While Boost is definitely a great (mostly) header-only library, it's complexity and size can quickly become a pain in the ass...

[nonstickfrypan]

After some inspection, I don't really believe. Take the boost::property_tree::ptree as an example. the ptree is just special case of boost::property_tree_tree which is a template and it uses huge amount of templates and includes. I tried the /P option (thanks for that), to see how many lines it includes, and it is 316 978 (more than all the lines including in cpp files in our whole project). I understand that the guys from boost wants to share all the code and make everything perfectly expandable and general. But if I make my own custom ptree that is not a template, so lot of the functionality can be hidden in .cpp and when it is simplified, it suddenly can use up thousandth of the lines in the include. And I strongly believe that the compilation is then also faster, as it is very often using just simple class methods, instead of making build (repeatedly) template code in the header in every module when it is used. And it will be also faster in runtime, as I can optimise the ptree for our use with state memory pool.

I'm not sure why you have to create your own property_tree from scratch. Can't you make your own property tree class based on the Boost version that does what you need it do do without templates (i.e. the class member functions etc would be the same as one you created from scratch, but instead of writing all the logic have your class basically as an abstraction layer on top of boost::property_tree... let it do the actual implementation). That way your class can be in its own file and you avoid parsing 316978 lines of code for every file that uses it; they would only be parsed if you change your "wrapper class" or whatever fancy name you wish to call it

Edit: Don't include #include <boost/property_tree/whatever.hpp> in your custom classe's header file of course... only include those things in the .cpp and hide as much as you can so that the only time those boost files get parsed is if your .cpp changes.

[cube]

After some inspection, I don't really believe. Take the boost::property_tree::ptree as an example. the ptree is just special case of boost::property_tree_tree which is a template and it uses huge amount of templates and includes. I tried the /P option (thanks for that), to see how many lines it includes, and it is 316 978 (more than all the lines including in cpp files in our whole project). I understand that the guys from boost wants to share all the code and make everything perfectly expandable and general. But if I make my own custom ptree that is not a template, so lot of the functionality can be hidden in .cpp and when it is simplified, it suddenly can use up thousandth of the lines in the include. And I strongly believe that the compilation is then also faster, as it is very often using just simple class methods, instead of making build (repeatedly) template code in the header in every module when it is used. And it will be also faster in runtime, as I can optimise the ptree for our use with state memory pool.

I'm not sure why you have to create your own property_tree from scratch. Can't you make your own property tree class based on the Boost version that does what you need it do do without templates (i.e. the class member functions etc would be the same as one you created from scratch, but instead of writing all the logic have your class basically as an abstraction layer on top of boost::property_tree... let it do the actual implementation). That way your class can be in its own file and you avoid parsing 316978 lines of code for every file that uses it; they would only be parsed if you change your "wrapper class" or whatever fancy name you wish to call it :)

Edit: Don't include #include <boost/property_tree/whatever.hpp> in your custom classe's header file of course... only include those things in the .cpp and hide as much as you can so that the only time those boost files get parsed is if your .cpp changes.

It's not just compile time, but run time too. property tree is just too general for us.

[ratchetfreak]

if you want to keep a log of how your build times evolve then you could use ctime, a public domain timing utility created by a guy that cares about his build times way too much.

https://www.youtube.com/watch?v=LdMHyGxfg6U

https://gist.github.com/mmozeiko/4972c2 ... 089eec7083

[Harkonnen604]

Compilation time can be resolved by using Incredibuild (but this stuff is expensive and assumes big office with many cores). Another option is FastBuild (I guess that's what unity means). It manages to reduce compilation time, but more important it reduces link time. On a big project that compiles like 20 minutes locally (and links like 5 minutes) the overall process took 2-3 minutes. And even incremental compilation/linking worked fine

As for custom stl/boost - I wrote these things and would happily port that for Factorio.

[searker]

Compilation time can be resolved by using Incredibuild (but this stuff is expensive and assumes big office with many cores). Another option is FastBuild (I guess that's what unity means). It manages to reduce compilation time, but more important it reduces link time. On a big project that compiles like 20 minutes locally (and links like 5 minutes) the overall process took 2-3 minutes. And even incremental compilation/linking worked fine

As for custom stl/boost - I wrote these things and would happily port that for Factorio.

They switched to FastBuild a few weeks / months ago and mentioned it in two or three FFF´s

[Harkonnen604]

Good to hear! I'm new here at the board after my 5th rocket. Still roaming through fresh FFFs. fun to see how they converge