5 ms·

Just to make sure I'm understanding this correctly: the performance issue you found actually amounts to include-order dependent behavior in GCC and glibc; clan

Just to make sure I'm understanding this correctly: the performance issue you found actually amounts to include-order dependent behavior in GCC and glibc; clang doesn't really have anything to do with anything here except that you used its code formatter to sort your include statements. If that's the case, the clickbait-y headline's bordering on useless, since the performance differences here have nothing to do with clang itself-- you'd see the same results if you had ordered your includes the same way by hand.

big_chungus 7y ago
No, the headline pretty clearly states "Clang Format". I've used clang-format on MSVC codebases, and imagine there are some who use it with GCC (say, for instance, the author). It's still the best C++ formatter, as far as I know, and is compiler-independent.
- BeeOnRope 7y ago
  It's basically the gorilla in the space, and it's good. There is no gcc equivalent. In any case there no 1:1 relationship between formatters anyways: you might compiler you codebase with N compilers, but you'll only have one formatter unless you are insane. So my codebases are not "gcc" or "clang" codebases, but basically "linux" codebases - but the formatter is always clang-format.
BeeOnRope 7y ago
I'm talking about clang-format, a formatting tool for C and C++ code, which has nothing to do with compiling your code with clang. You can use it with any compiler. That said, the title is still a lie in that clang-format is not really at a fault here at all: clang-format triggered the issue on my codebase, by sorting header files, and this in turn triggered a libc performance issue. So as I initially say it, a commit which purely clang-format 'd my codebase caused a massive regression - but the full story is doesn't implicate clang-format at all, really.
- glandium 7y ago
  The title would be a /little/ clearer with a dash between Clang and format.
  - ndesaulniers 7y ago
    Or "header inclusion order may affect performance." If someone points to this as a reason not to use clang-format...
  - BeeOnRope 7y ago
    Good point, I put a hyphen a few places but not everywhere nor in the title. It seems hyphen is definitely the standard though. Fixed now [1], although the HN title will remain hyphen-free free I guess. --- [1] https://github.com/travisdowns/travisdowns.github.io/commit/95c6788e011eaa9638e12223d6d7dbd0465e5d8f https://github.com/travisdowns/travisdowns.github.io/commit/...
- dleslie 7y ago
  clang-format reordering includes is a terrible behaviour. It would break many C/C++ projects.
  - glandium 7y ago
    It's optional, although it's enabled by default in the LLVM and Chromium styles.
    - dleslie 7y ago
      That's a bizarre optional feature to have; it's tantamount to having a "blindly reorder logic" function that sorts your source alphanumerically.
      - defap 7y ago
        Not really too bizarre. Header files should include or declare everything they need; they should not introduce include-order dependencies. Listing your includes in lexicographic order is a good way to enforce header completeness.
twic 7y ago
It would actually be interesting to see if this phenomenon happens with clang, which has its own implementation of the standard library. And perhaps with musl libc or some such.
- BeeOnRope 7y ago
  Clang has its own libc++ implementation, but I think clang still uses the system libc and associated headers?
  - twic 7y ago
    Yes, i think so too. So a different <algorithm>, but the same <ctype.h>. The crucial __NO_CTYPE define is in <bits/os_defines.h>, which is part of the GCC paraphernalia. I don't know if clang's stdlib would also have to end up defining it.

big_chungus 7y ago

No, the headline pretty clearly states "Clang Format". I've used clang-format on MSVC codebases, and imagine there are some who use it with GCC (say, for instance, the author). It's still the best C++ formatter, as far as I know, and is compiler-independent.

BeeOnRope 7y ago
It's basically the gorilla in the space, and it's good. There is no gcc equivalent. In any case there no 1:1 relationship between formatters anyways: you might compiler you codebase with N compilers, but you'll only have one formatter unless you are insane. So my codebases are not "gcc" or "clang" codebases, but basically "linux" codebases - but the formatter is always clang-format.

BeeOnRope 7y ago

I'm talking about clang-format, a formatting tool for C and C++ code, which has nothing to do with compiling your code with clang. You can use it with any compiler. That said, the title is still a lie in that clang-format is not really at a fault here at all: clang-format triggered the issue on my codebase, by sorting header files, and this in turn triggered a libc performance issue. So as I initially say it, a commit which purely clang-format 'd my codebase caused a massive regression - but the full story is doesn't implicate clang-format at all, really.

glandium 7y ago
The title would be a /little/ clearer with a dash between Clang and format.
- ndesaulniers 7y ago
  Or "header inclusion order may affect performance." If someone points to this as a reason not to use clang-format...
- BeeOnRope 7y ago
  Good point, I put a hyphen a few places but not everywhere nor in the title. It seems hyphen is definitely the standard though. Fixed now [1], although the HN title will remain hyphen-free free I guess. --- [1] https://github.com/travisdowns/travisdowns.github.io/commit/95c6788e011eaa9638e12223d6d7dbd0465e5d8f https://github.com/travisdowns/travisdowns.github.io/commit/...
dleslie 7y ago
clang-format reordering includes is a terrible behaviour. It would break many C/C++ projects.
- glandium 7y ago
  It's optional, although it's enabled by default in the LLVM and Chromium styles.
  - dleslie 7y ago
    That's a bizarre optional feature to have; it's tantamount to having a "blindly reorder logic" function that sorts your source alphanumerically.
    - defap 7y ago
      Not really too bizarre. Header files should include or declare everything they need; they should not introduce include-order dependencies. Listing your includes in lexicographic order is a good way to enforce header completeness.

twic 7y ago

It would actually be interesting to see if this phenomenon happens with clang, which has its own implementation of the standard library. And perhaps with musl libc or some such.

BeeOnRope 7y ago
Clang has its own libc++ implementation, but I think clang still uses the system libc and associated headers?
- twic 7y ago
  Yes, i think so too. So a different <algorithm>, but the same <ctype.h>. The crucial __NO_CTYPE define is in <bits/os_defines.h>, which is part of the GCC paraphernalia. I don't know if clang's stdlib would also have to end up defining it.