Paul Koning writes:
> >>>>> "Andrew" == Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> >> However, I can always tell when a GCC build has hit the libjava
> >> build -- that's when the *whole system* suddenly slows to a crawl.
> >> Maybe it comes from doing some processing on 5000 foo.o files all
> >> at once... :-(
>
> Andrew> But that is not GCC fault that binutils cannot handle that
> Andrew> load.
>
> Perhaps not. But perhaps there are workarounds that allow the gcc
> build to do its job without using binutils in a way that stresses it
> beyond its ability to cope.
>
> Matt's time output suggests that massive pagefaulting is a big issue
I'm sure that's true. The working set exceeds the amount of RAM in
the system, leading to near worst-case behaviour.
> -- and it wouldn't surprise me if the libjava build procedure were a
> major contributor there.
Yes. This is a profile of the libgcj build. The single biggest user
of CPU is the libtool shell script, which uses more than a quarter of
the total (non-kernel) CPU time. However, it's important not to be
misled -- I'm sure the linker causes a huge amount of disk activity,
so it's not just CPU time that is important.
Having said that, I suspect that the single biggest improvement to the
libgcj build time would be either to remove the libtool shell script
altogether or find some way to reduce its use or make it faster.
CPU: CPU with timer interrupt, speed 0 MHz (estimated)
Profiling through timer interrupt
TIMER:0|
samples| %|
------------------
1770547 63.0596 no-vmlinux
415708 14.8058 libc-2.3.4.so
259889 9.2562 ltsh
257355 9.1659 jc1
22111 0.7875 cc1plus
20260 0.7216 as
19289 0.6870 ld-2.3.4.so
10502 0.3740 make
5921 0.2109 sed
5163 0.1839 libbfd-2.15.92.0.2.so
2855 0.1017 gcj
2724 0.0970 cc1
2218 0.0790 libz.so.1.2.1.2
2154 0.0767 grep
2019 0.0719 xterm
1864 0.0664 ld
Andrew.
