This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Suggestion for improving C++ parser memory usage
Steven Bosscher wrote:
On Dec 30, 2004 02:18 PM, Robert Dewar <dewar@adacore.com> wrote:
Significant memory reductions are certainly of interest, but it seems
very dubious that this particular suggestion would pay off,
Hellooooo!!! Have you learned nothing from observing the past few
years of GCC development?
I guess one thing I have learned is that gcc, already very slow and
big from the start, seems to be getting slower and bigger. I actually
think of gcc as being 1-2 decimal orders of magnitude slower and bigger
than it should be if it were really designed for speed and space. However,
this goal does get less important as time goes on. It was interesting
experience in this regard to see that when the first diskette based
PC's came out with 640K of memory max, the fact that Realia COBOL
compiled 10,000 lpm, and the competition compiled 1,000 lpm was a
real advantage, but by the time we got to 386's, it was less of
an advantage to compile 100,000 lpm over the competition's 10,000 lpm,
since the latter was fast enough for many people. Now Realia COBOL
probably compiles millions of lines/minute, but it is really less
important than it used to be. It also runs fine in a couple of
megabytes, and will manage reasonably in 256K of memory but again
that is less important than it used to be.
I am all in favor of significant improvements in space and speed of
GCC. In fact with my AdaCore hat on, we have customers using slow
machines that definitely find the speed of the compiler (and in some
cases the space [though see below]) a problem. For the most part
x86 users find the speed OK, but not all the world uses x86's
for develpment.
I just don't think you make very much progress by making small
incremental changes. Yes, I know what 1.01**10 is, but the trouble
is that many of these changes operate far below the 1% level. I
am pretty confident that the proposed change is in this category
though certainly I don't object to someone giving it a try if
it does not murkify the parser too much.
Regarding space. I have never seen a case where 5-10% was the issue.
Rather, it has been cases where there is some algorithm in the compiler
that is using up unpleasant non-linear amounts of memory, and where
a relatively small change can make huge algorithmic differences in
memory usage (in one case cutting down required memory from gigabytes
to 10's of megabytes). Such changes are definitely worth while!