Messages in this thread | | | From | David Laight <> | Subject | RE: mainline build failure due to 281d0c962752 ("fortify: Add Clang support") | Date | Thu, 23 Jun 2022 10:12:15 +0000 |
| |
From: Nick Desaulniers > Sent: 22 June 2022 23:40 .... > > We don't actually take full advantage of that, because we do end up > > doing a real "build" of an empty file, so "cc1" does actually get > > executed, but even then it's done fairly efficiently with 'vfork()'. > > That "cc-option" part of the kernel build is actually noticeable > > during configuration etc, and clang is *much* slower because of how it > > is built. > > > > See > > > > time clang -Werror -c -x c /dev/null > > > > and compare it with gcc. And if you want to see a really *big* > > difference, pick a command line option that causes an error because it > > doesn't exist.. > > Looking at a profile, there's a lot of stupid stuff we're doing. We > can probably get faster "at doing nothing." See > https://gist.github.com/nickdesaulniers/81a87ffa784c13d0bf60f60b1d54651b > for the profile and my commentary/initial thoughts. > > > > > I really wish clang wasn't so much noticeably slower. It's limiting > > what I do with it, and I've had other developers say the same. > > We can do better. I'll keep pushing on this up my chain of command. > That statement stands in stark contrast to the below:
The slow startup must also make a big difference to anything that uses autoconf. That tends to run a lot of compiles of trivial code just to find out that the system is 'normal'.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
| |