Announcement

Collapse
No announcement yet.

LLVM Clang 11 Has A Nice Build Speed Improvement With New Feature For Pre-Compiled Headers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • LLVM Clang 11 Has A Nice Build Speed Improvement With New Feature For Pre-Compiled Headers

    Phoronix: LLVM Clang 11 Has A Nice Build Speed Improvement With New Feature For Pre-Compiled Headers

    There are many improvements in LLVM/Clang 11.0 due out in the weeks ahead though an interesting change merged prior to last month's code branching that slipped under our radar... If using the clang-cl driver for MSVC or when otherwise making use of pre-compiled headers (PCH) functionality, there is a new option that can offer significant build time speed-ups...

    http://www.phoronix.com/scan.php?pag...H-Instant-Temp

  • #2
    Awesome!! I actually wondered why this wasn't a thing just a few weeks ago. In my C++ codebase this caused pchs to be far less efficient than they could be because a lot of time was wasted on common template instantiations.

    Comment


    • #3
      I decided to come back to C after quite a few years doing OOP with C++. I realized that what I really want is a stable language that can be compiled even in very old OSs, and besides you can apply the OOP paradigm in C as well, and in a very clean-concept way, as a number of well designed toolkits do.

      But I'm still interested in LLVM 11 compile times, because it was reported that LLVM 10 was slower than LLVM 9 at compiling, and I'm assuming that it was not only for C++, but for C too. So, I wish they have improved the compile times for C too.

      P.S: What a peace of mind, not having to deal with pch anymore, nor with any nightmares like that.

      Comment


      • #4
        Originally posted by cesarcafe View Post
        I decided to come back to C after quite a few years doing OOP with C++. I realized that what I really want is a stable language that can be compiled even in very old OSs, and besides you can apply the OOP paradigm in C as well, and in a very clean-concept way, as a number of well designed toolkits do.

        But I'm still interested in LLVM 11 compile times, because it was reported that LLVM 10 was slower than LLVM 9 at compiling, and I'm assuming that it was not only for C++, but for C too. So, I wish they have improved the compile times for C too.

        P.S: What a peace of mind, not having to deal with pch anymore, nor with any nightmares like that.
        I know you didn't explicitly ask for advice, but...

        Have you tried using -ftime-trace to analyze what takes up time in your codebase?

        If a significant amount of time is put in parsing files, it is not unlikely that you could cut down your compile times actually using precompiled headers.
        Unity builds may help as well for full build times (probably not for incremental compile times).
        Both rely on a build system that support these features though, and these are probably much less effective than in C++ indeed.

        -gsplit-dwarf may be helpful as well in some scenarios if debug symbols slow your build down.

        Also, if linking takes up time, try -fuse-ld=lld.

        Comment


        • #5
          Originally posted by AsuMagic View Post

          I know you didn't explicitly ask for advice, but...

          Have you tried using -ftime-trace to analyze what takes up time in your codebase?

          If a significant amount of time is put in parsing files, it is not unlikely that you could cut down your compile times actually using precompiled headers.
          Unity builds may help as well for full build times (probably not for incremental compile times).
          Both rely on a build system that support these features though, and these are probably much less effective than in C++ indeed.

          -gsplit-dwarf may be helpful as well in some scenarios if debug symbols slow your build down.

          Also, if linking takes up time, try -fuse-ld=lld.
          Thanks a lot Anyway, my move from C++ to C is not because of compile times, but because of concept. Every year, I dislike the C++ approach to OOP more and more, while I keep rediscovering I can write C with an OOP paradigm, much cleaner, with better performance, far away from crazy cryptic compile errors arising from templates, and far away from the shocking forced obsolescence of writing new C++ compilers using a brand-new C++ standard (I don't like the idea of putting at risk the future compatibility of my code just because a C++17 compiler needs a C++14 compiler to be built, which in turn needs a very recent C++ library, which depends on you having a mainstream and current OS because libC++ is implemented from scratch on top of syscalls instead of being built on top of a more standard POSIX libC).

          IMHO, C++ was a good attempt in the early days of cfront. It was promising (some ideas were wrong and they were better solved in ObjectiveC, but then you need to consider that Stroustrup had some tastes and preferences that he couldn't resist to put into C++). Anyway, at that time, C++ was very promising. But then, when the STL was developed, and when cfront was abandoned, C++ took a direction completely opposite to my development strategies.

          So, I'm back to C, and I don't plan to switch back to C++ anymore. I'd rather write a new cfront than going back to the craziness of new C++ standards that clutter the language, add unnecessary complexity, and don't add necessary features (where's reflection and type introspection after all these years?????)

          Yes, I know this is offtopic, but just to clarify your answer, because I didn't move for performance.
          Last edited by cesarcafe; 08-13-2020, 06:09 AM.

          Comment

          Working...
          X