Comment 7 for bug 398403

19:06 < lool> cjwatson: I built with -O0 -fno-common -fno-foo ... disabling all
              enabled opts until the output would only mention one enabled opt
              which is the reverse of another one; the build still takes
              hundreds of megs of RAM and I stop it at around 80 % RAM after 3
              minutes
19:07 < lool> I guess I should have tried with an unpatched gcc though
...
19:08 < lool> Oh it passed
19:08 < lool> after 4 minutes or so
19:09 < lool> but using a big load of RAM
...
19:12 < lool> doko: I don't quite know how to attack the upstart build slowness
              issue
19:12 < lool> Basically, we're seeing underperformance, but it's hard to
              qualify how fast gcc should run, or how much memory it's allowed
              to use
19:12 < lool> doko: Do you think some patches we're using could be destroying
              performance?
19:12 < lool> e.g. that 64 bytes align patch
19:13 < lool> That's a binutils patch, but I can see how it could lead to much
              larger RAM usage
19:13 < doko> lool: where is the time used, in cc1, or as?
19:13 < lool> doko: cc1
19:14 < doko> well, then it's not the align patch, and we are pretty much using
              upstream, no fancy patches on our own
19:15 < lool> doko: Can I just report it upsteam opening a new bug saying that
              it uses a load of RAM/CPU to build a file?
19:15 < lool> ie Is that an acceptable bug?
19:16 < doko> lool: sure, better check it with 4.3 (or older) as well to see if
              it's a regression or not.
...
19:23 < lool> doko: It's about the same performance with gcc-4.3