At 02:28 PM 1/22/2001 -0500, you wrote:
>Over the weekend I did some simple compiler tests on the NetBSDs
>and other OS's I have up on my MicroVAX II critters.

Thank you Bob for investing this time, solid numbers are always better than 
"it feels slower." !

>OS                           Gkermit compile time (m:s)
>--------------------------   --------------------------
>4.3BSD-Tahoe PCC             3:01
>Ultrix 4.2 VAX-C             2.50
>NetBSD-1.2 gcc 2.72          5:05
>NetBSD-1.3 gcc 2.72.1        6:07
>NetBSD-1.4.3 gcc 2.91        7:08
>NetBSD-1.5 gcc 2.91          7:40
>--------------------------   --------------------------

Try compiling it with pcc on the NetBSD 1.5 system, using 4.3 
compatibility. I suspect you will get about 3:20 for that one.


 > Clearly, the effects of bloat are beginning to overburden
 > the lowly slower-than-1-VUP box. ... Ultrix C is well optimized
 > for running on the VAX. gcc 2.91 sucks on slow machines.

This is my current candidate for attack. One of the issues with EGCS and 
the GCC folks getting together is that the GCC folks brought the "PC 
Mindset" which includes the feeling that memory is free. Anyone who has 
written a compiler will tell you that you can burn memory to get better 
optimizations quickly. This is what GCC seems to do most often. The impact 
is a bigger memory footprint for the GCC image as it runs, which causes 
swapping which causes slowness. I now run with an MFS /tmp on my build 
machine and with TMPDIR set to /tmp to speed things up (it does by about 
30%) But that only works on machines where you can burn memory (and 
explains why I want to make my 4000/90 128M :-)

The last time I complained about this to the EGCS folks the answer was "but 
PeeCees are so cheap, just buy one and cross compile!" Not my answer of choice.

--Chuck