Hi, On 2023-12-15 22:19:56 -0500, Tom Lane wrote: > Thomas Munro <thomas.mu...@gmail.com> writes: > > On Sat, Dec 16, 2023 at 3:44 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Thomas Munro <thomas.mu...@gmail.com> writes: > >>> FYI, it looks like there is a big jump in CPU time to compile preproc.c > >>> at -O2: > >>> clang15: ~16s > >>> clang16: ~211s > >>> clang17: ~233s
Is this with non-assert clangs? Because I see times that seem smaller by more than what can be explained by hardware differences: preproc.c: 17 10.270s 16 9.685s 15 8.300s gram.c: 17 1.936s 16 2.131s 15 2.161s That's still bad, but a far cry away from 233s. > Huh. There's not that many more productions in the ecpg grammar > than the core, so it doesn't seem likely that this is purely a > size-of-file issue. I'd bet on there being something that clang > doesn't do well about the (very stylized) C code being generated > within the grammar productions. > > We actually noticed this or a closely-related problem before [1] > and briefly discussed the possibility of rearranging the generated > code to make it less indigestible to clang. But there was no concrete > idea about what to do specifically, and the thread slid off the radar > screen. One interest aspect might be that preproc.c ends up with ~33% more states than gram.c gram.c: #define YYLAST 116587 preproc.c: #define YYLAST 155495 Greetings, Andres Freund
