Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clang Format Tanks Performance

travisdowns.github.io

Post reply on HN
Print view View original

71–80 of 156 posts

Re: Clang Format Tanks Performance

#71

Post by dleslie »

TwoBit wrote: post #66
dleslie wrote: post #51

Earlier quoted context omitted.

Of course clang format is at fault; reordering includes, even standard or system includes, will almost certainly effect how a complex C/C++ program compiles. That's just how it is, with the preprocessor and such. This is a _bad_ clang-format bug.

That reordering is simply a feature of clang-format. Some coding standards require sorting includes alphabetically, possibly to avoid dupes and to make all include usage identical between source files.

In terms of C/C++ headers, that's like requiring all scopes have their expressions alphanumerically sorted.

C/C++ headers are literal code-injection mechanisms; they aren't modifying a runtime environment by importing symbols, they inject code into the compilation unit.

Re: Clang Format Tanks Performance

#72

Post by glandium »

dleslie wrote: post #70
defap wrote: post #68

Earlier quoted context omitted.

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.

It is by convention that C/C++ headers rely on preprocessor state to determine what blocks to reveal, macros to use, et al. It is quite common to have an auto-generated configuration header, for instance; or a precompiled header; or optional headers that, when present, mutate the behaviour of other headers. Every time you run a configure script for a C project there's a good chance you're interacting with code in thi…

clang-format still allows some ordering when the SortIncludes feature is enabled. Search for IncludeBlocks in https://clang.llvm.org/docs/ClangFormatStyleOptions.html

Re: Clang Format Tanks Performance

#73

Post by fizwhiz »

BeeOnRope wrote: post #36
gpm wrote: post #31

Earlier quoted context omitted.

I'm going to take the contrarian view here, and say it's not clickbait. I admit that I'm not a C++ expert, but naively I would never have expected clang-format to have any effect on my code. If you stopped and suggested header re-ordering to me my first thought would have been "I guess it must not do that. Maybe in practice header re-ordering doesn't actually matter with reasonable code?". The title here doesn't desc…

I agree with most of that, although as the author I think it's still clickbait in the sense that: 1) clang-format is not really at fault here at all - the same effect could have happened by adding a new header, reordering the headers manually, switching to a system with a different libc version or a different transitive header include tree, etc. 2) The title doesn't tell you wtf is up. You have to get at least half w…

> Except for the crypto mining bot I load into your browser, and which subsequently writes itself to your MBR or UEFI partition

Guess I won't be clicking on the link now.

Re: Clang Format Tanks Performance

#74

Post by skrebbel »

fizwhiz wrote: post #73
BeeOnRope wrote: post #36

Earlier quoted context omitted.

I agree with most of that, although as the author I think it's still clickbait in the sense that: 1) clang-format is not really at fault here at all - the same effect could have happened by adding a new header, reordering the headers manually, switching to a system with a different libc version or a different transitive header include tree, etc. 2) The title doesn't tell you wtf is up. You have to get at least half w…

> Except for the crypto mining bot I load into your browser, and which subsequently writes itself to your MBR or UEFI partition Guess I won't be clicking on the link now.

You're missing out. It's a great article, definitely worth all that monero.

Re: Clang Format Tanks Performance

#76

Post by rdc12 »

pvg wrote: post #35
BeeOnRope wrote: post #30

Earlier quoted context omitted.

Got it, I didn't understand you were talking about HN titles, rather than the blog post title. I didn't submit it to HN so I can't comment on the title choice, other than say it at least reflects the literal title of the page which I guess would be the default when submitting. I tend to outsource my comments to HN, since my blog is a github pages static site and introducing comments without tracking and ads is a pain…

Right, technically, fixing the title in this case would have been on the poster. Then there'd probably be a long subthread about why the title was changed so drastically. Title-lawyering is a professional metasport around here, as has been amply demonstrated.

Pretty much the HN version of nerd sniping.

https://xkcd.com/356/

Re: Clang Format Tanks Performance

#77

Post by sanxiyn »

dleslie wrote: post #51
BeeOnRope wrote: post #36

Earlier quoted context omitted.

I agree with most of that, although as the author I think it's still clickbait in the sense that: 1) clang-format is not really at fault here at all - the same effect could have happened by adding a new header, reordering the headers manually, switching to a system with a different libc version or a different transitive header include tree, etc. 2) The title doesn't tell you wtf is up. You have to get at least half w…

Of course clang format is at fault; reordering includes, even standard or system includes, will almost certainly effect how a complex C/C++ program compiles. That's just how it is, with the preprocessor and such. This is a _bad_ clang-format bug.

You can disable include reordering in clang-format. I don't think this is a bug, because I see the default here as a matter of policy decision.

Re: Clang Format Tanks Performance

#78

Post by slavik81 »

BeeOnRope wrote: post #29
pydave wrote: post #18

Earlier quoted context omitted.

> Are my standard algorithms letting me down? Does std::transform have some fatal flaw? Not really. Well, not at all. This part lost me because I can't see how you can use std::transform (which is in ) without hitting this flaw. Unless you edit the headers? I guess you mean the algorithm isn't flawed. I also didn't understand the title because I don't use clang-format and I skimmed past the single mention of it (my f…

The title was basically clickbait. It reflects how I encountered the issue, but the investigation doesn't have much of that, because I was starting from a point where I suddenly had a slow and fast algorithm (the actual scenario was more complicated than shown). The investigation doesn't have much to do with clang-format because I'm just trying to see why a raw loop is faster, and ultimately has nothing to do with "r…

I bet the performance would look different in a real program anyways. The random input data probably results in more branch predict misses than would occur in normal text, and the tight loop of the benchmark basically ensures the lookup table is always in cache.
Post reply on HN