On Sat, Aug 06, 2022 at 08:05:14PM -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2022-08-06 16:09:24 -0700, Noah Misch wrote: > >> From the earliest days of wrasse, the compiler used too much RAM to build > >> preproc.o with --enable-debug. As of 2021-04, the compiler's "acomp" phase > >> needed 10G in one process, and later phases needed 11.6G across two > >> processes. > >> Compilation wrote 3.7G into TMPDIR. Since /tmp consumes RAM+swap, > >> overriding > >> TMPDIR relieved 3.7G of RAM pressure. Even with those protections, wrasse > >> intermittently reaches the 14G limit I impose (via "ulimit -v 14680064"). > >> I > >> had experimented with different optimization levels, but that didn't help. > > > Yikes. And it's not like newer compiler versions are likely to be > > forthcoming > > (12.6 is newest and is from 2017...). Wonder if we should just require gcc > > on > > solaris... There's a decent amount of stuff we could rip out in that case. > > Seems like it's only a matter of time before we add enough stuff to > the grammar that the build fails, period.
I wouldn't worry about that enough to work hard in advance. The RAM usage can grow by about 55% before that's a problem. (The 14G ulimit can tolerate a raise.) By then, the machine may be gone or have more RAM. Perhaps even Bison will have changed its code generation. If none of those happen, I could switch to gcc, hack things to use gcc for just preproc.o, etc. > So there's something pretty bloated there. It doesn't seem like > ecpg's additional productions should justify a nigh 50% code > size increase. True.
