> steps a) and b) used the same library. So it is not an increase in the > library size.
Ok > The crucial thing was that the compiler was significantly > change soas to require more ram to compile the test library. Sure, you expect that, and I outlined some possible reasons. Now some facts please about the resulting code when compiled with the new compiler instead of the old one, or else please stop whinging. If the code now runs twice as fast at 80% of its size but compiling the source takes 4x as much RAM, I count that as a significant improvement of gcc. No doubt there's a switch to turn it off again. If you don't like it, use the old compiler. But it's all speculation of course until you answer these relevant questions (which you should have done together with your first complaint about gcc). I find it hard to believe that the gcc team would quadruple the resource requirements of their software for zero gain. You seem to be measuring bloat by its cost, but it seems better to me to define bloat as gain divided by cost. > But if the library is much bigger, there will be more cache misses in the > CPU. s/library/code/ What are you talking about here? The compiler? Your library code? And code speed and efficiency is not easily assessable or predictable these days, by the way. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
