4 ms·

The article isn't about cleaning up header files. I don't think anyone criticizing the article is claiming that reducing the amount of code in header files will

by Kranar 4y ago

The article isn't about cleaning up header files. I don't think anyone criticizing the article is claiming that reducing the amount of code in header files will speed up compile times. The burden that the author should substantiate with evidence instead of claiming that he's a genius or a madman is whether moving includes out of header files and into source files as a strategy to avoid including the same header file multiple times has an effect on compile times. Most people criticizing this article, including myself, argue that it does not (along with reasons why, such as header guards and the optimizations that compilers include to recognize them).

db48x 4y ago
The rule to never include anything from a header is just the ultimate cleanup. I reiterate that I think it is unfortunate that the author of this article collected no numbers. It would be interesting to compare them to the Linux kernel’s numbers: | v5.16-rc7 | -fast-headers-v1 |--------------------------------|--------------------------------------- 'touch include/linux/sched.h' | 230.30 secs | 15.6 builds/hour | 108.35 secs | 33.2 builds/hour | +112% 'touch include/linux/mm.h' | 216.57 secs | 16.6 builds/hour | 79.42 secs | 45.3 builds/hour | +173% 'touch include/linux/fs.h' | 223.58 secs | 16.1 builds/hour | 85.52 secs | 42.1 builds/hour | +161% 'touch include/linux/device.h' | 224.35 secs | 16.0 builds/hour | 97.09 secs | 37.1 builds/hour | +132% 'touch include/net/sock.h' | 105.85 secs | 34.0 builds/hour | 40.88 secs | 88.1 builds/hour | +159% Doubling and nearly tripling the compile speed is a huge win! But the really eye–opening numbers are further down. Here are the first few rows from the table: ------------------------------------------------------------------------------------------ | Combined, preprocessed C code size of header, without line markers, | with comments stripped: ------------------------------.-----------------------------.----------------------------- | v5.16-rc7 | -fast-headers-v1 |-----------------------------|----------------------------- #include <linux/sched.h> | LOC: 13,292 | headers: 324 | LOC: 769 | headers: 64 #include <linux/wait.h> | LOC: 9,369 | headers: 235 | LOC: 483 | headers: 46 #include <linux/rcupdate.h> | LOC: 8,975 | headers: 224 | LOC: 1,385 | headers: 86 #include <linux/hrtimer.h> | LOC: 10,861 | headers: 265 | LOC: 229 | headers: 37 #include <linux/fs.h> | LOC: 22,497 | headers: 427 | LOC: 1,993 | headers: 120 Note in particular that sched.h includes, directly or indirectly, 324 _unique_ header files. Header guards are not going to help you here, because there are still 13k lines of code to parse and compile. The speedup comes from reducing this to 64 unique headers and just 769 lines of code to compile. You cannot rely solely on #pragma once or header guards. You should definitely use them for correctness, but if that’s all you do you will leave a lot of compile–time performance on the table.
- Kranar 4y ago
  >The rule to never include anything from a header is just the ultimate cleanup. What? No the two have nothing to do with one another. The clean up in the Linux kernel involves having more granular includes, that is breaking up very large header files on the order of 10s of thousands of lines of code that often include unrelated or independent declarations, down into smaller header files that are on the order of 100-1000 lines of code and whose declarations are tightly coupled. I don't think many people would argue against breaking down large catch-all header files into smaller independent header files so that a consumer only needs to include what they need instead of having to include everything and the kitchen sink. >Note in particular that sched.h includes, directly or indirectly, 324 _unique_ header files. Header guards are not going to help you here... Of course not, and no one is claiming it will. It's also not going to help you if you decide to move all of those 324 unique header files into your .c file which is all this article is suggesting you do. What will help you is to refactor your dependencies so that you don't need to include 324 header files to begin with and instead can reduce your includes down to some minimal set. Once you've broken your dependencies down to a minimal set of headers, it won't matter whether you include that minimal set in a .c file or a .h file, what matters is that you've reorganized your dependencies to avoid having a bunch of declarations that are independent of one another. Ultimately you're conflating two very different concepts under the vague term "cleanup". Having granular header files is something many people would agree makes compile times faster and also just improves overall software quality, by all means do it. Moving all your includes from .h into .c is just some kind superficial cargo-cult programming and will have no material impact on compile times or quality.

by Kranar 4y ago

db48x 4y ago

The rule to never include anything from a header is just the ultimate cleanup. I reiterate that I think it is unfortunate that the author of this article collected no numbers. It would be interesting to compare them to the Linux kernel’s numbers: | v5.16-rc7 | -fast-headers-v1 |--------------------------------|--------------------------------------- 'touch include/linux/sched.h' | 230.30 secs | 15.6 builds/hour | 108.35 secs | 33.2 builds/hour | +112% 'touch include/linux/mm.h' | 216.57 secs | 16.6 builds/hour | 79.42 secs | 45.3 builds/hour | +173% 'touch include/linux/fs.h' | 223.58 secs | 16.1 builds/hour | 85.52 secs | 42.1 builds/hour | +161% 'touch include/linux/device.h' | 224.35 secs | 16.0 builds/hour | 97.09 secs | 37.1 builds/hour | +132% 'touch include/net/sock.h' | 105.85 secs | 34.0 builds/hour | 40.88 secs | 88.1 builds/hour | +159% Doubling and nearly tripling the compile speed is a huge win! But the really eye–opening numbers are further down. Here are the first few rows from the table: ------------------------------------------------------------------------------------------ | Combined, preprocessed C code size of header, without line markers, | with comments stripped: ------------------------------.-----------------------------.----------------------------- | v5.16-rc7 | -fast-headers-v1 |-----------------------------|----------------------------- #include <linux/sched.h> | LOC: 13,292 | headers: 324 | LOC: 769 | headers: 64 #include <linux/wait.h> | LOC: 9,369 | headers: 235 | LOC: 483 | headers: 46 #include <linux/rcupdate.h> | LOC: 8,975 | headers: 224 | LOC: 1,385 | headers: 86 #include <linux/hrtimer.h> | LOC: 10,861 | headers: 265 | LOC: 229 | headers: 37 #include <linux/fs.h> | LOC: 22,497 | headers: 427 | LOC: 1,993 | headers: 120 Note in particular that sched.h includes, directly or indirectly, 324 _unique_ header files. Header guards are not going to help you here, because there are still 13k lines of code to parse and compile. The speedup comes from reducing this to 64 unique headers and just 769 lines of code to compile. You cannot rely solely on #pragma once or header guards. You should definitely use them for correctness, but if that’s all you do you will leave a lot of compile–time performance on the table.

Kranar 4y ago
>The rule to never include anything from a header is just the ultimate cleanup. What? No the two have nothing to do with one another. The clean up in the Linux kernel involves having more granular includes, that is breaking up very large header files on the order of 10s of thousands of lines of code that often include unrelated or independent declarations, down into smaller header files that are on the order of 100-1000 lines of code and whose declarations are tightly coupled. I don't think many people would argue against breaking down large catch-all header files into smaller independent header files so that a consumer only needs to include what they need instead of having to include everything and the kitchen sink. >Note in particular that sched.h includes, directly or indirectly, 324 _unique_ header files. Header guards are not going to help you here... Of course not, and no one is claiming it will. It's also not going to help you if you decide to move all of those 324 unique header files into your .c file which is all this article is suggesting you do. What will help you is to refactor your dependencies so that you don't need to include 324 header files to begin with and instead can reduce your includes down to some minimal set. Once you've broken your dependencies down to a minimal set of headers, it won't matter whether you include that minimal set in a .c file or a .h file, what matters is that you've reorganized your dependencies to avoid having a bunch of declarations that are independent of one another. Ultimately you're conflating two very different concepts under the vague term "cleanup". Having granular header files is something many people would agree makes compile times faster and also just improves overall software quality, by all means do it. Moving all your includes from .h into .c is just some kind superficial cargo-cult programming and will have no material impact on compile times or quality.