On Aug 2, 2012, at 3:43 AM, Julien Nitard <julien.nitard@m4tp.org> wrote:
On Thu, Aug 2, 2012 at 4:17 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Thu, Aug 2, 2012 at 2:36 AM, Daniel Larimer <dlarimer@gmail.com> wrote:
I have been increasingly frustrated with how long it takes to compile c++ code. After spending some time in Java and C# I can feel the pain of compile times much sharper than I use to. After seeing that Java and C# were able to achieve some level of generics without requiring 'everything in the header' and knowing that C compiles an order of magnitude faster than c++ I set about to find a way to increase my compile times.
Did you try PCH (precompiled headers)?
Well ... I did, they didn't work for me. Basically PCH resulted in a huge (200 MB-ish) file to be loaded for each CPP, a good portion of which was useless. Worse, I had to generate two PCHs : one for my shared libs and one for my binaries because they were not using the same compilers options. In addition, GCC options for PCH are not that easy to use / clear. What worked was parallel make, though it uses a lot of memory. Another clumsy and unpracical option was to #include my CPPs in another a larger one and compile that (it was one solution to another unrelated problem). It avoids repeating the preprocessing many times.
I also leverage the 'unity build' technique and have a CMAKE option to automatically build libraries I am not actively editing that way. It helps dramatically, but uses a ton of RAM and eliminates the 'partial build' forcing you to pay for a full build every time.
One of the common recommendations is to 'forward declare' everything and to use the PIMPL (private implementation pattern). Unfortunately, PIMPL usually implies heap allocation and if you ever want to return-by-value you are stuck including the entire header for the types you use in your header.
It'd be nice if a future version of C++ allowed pimpl without space overhead.
I am not sure why you are saying this, space is not the problem Daniel wants to address (though it be nice). Is it related to your message on std-proposal M.L. ? Daniel (and I ;) cares about Dymanic memory allocation. Though it would be good to measure whether modern allocators are very expensive or not ... I.E. if one couldn't replace forward by pimpl + efficient allocator. It may be worth measuring. I have been hearing about very efficient malloc implementation for a while without being able to test them practically. Does anyone have any experience ?
In multi-threaded applications, even very efficient allocators will lead to lock contention or excessive memory synchronization via the use of atomics. Besides, custom memory allocators are often a huge problem of their own.
Regards,
Julien
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost