Wiadomość napisana w dniu 2007-01-24, o godz23:52, przez Mike Stump:
On Jan 24, 2007, at 1:12 PM, Marcin Dalecki wrote:
One thing that would certainly help as a foundation for possible
further improvement in performance in this area would be to have
xgcc contain all the front ends directly linked into it.
That does seem debatable.
It could be a starting point to help avoiding quite a lot of
overhead needed to iterate over command line options for example.
Odd. You think that time is being spent iterating over the command
line options?
No I think plenty of time goes to dejagnu churning and iterative
restarts of new gcc process instances as well as other system calls.
That's at least what a casual look at a top and the sluggishness of
the disk system I'm using suggests. The option churning I did have in
mind was like
gcc -O0 test.c, gcc -01 test.c, gcc -O2 test.c
runs in sequence, which are quite common.
Do you have any data points to back this up? I suspect we're
spending less than 0.01% of the compilation time in duplicative
argument processing. After a quick check, yup, 0ms out of 1158 ms
are spent in option processing. 11 ms in xgcc, 1 ms in all of
xgcc, and 10 ms in system calls. So, I think due to measurement
error, I can say that no more than 0.17% of the time is spent in
duplicative option processing.
∎ Marcin Dalecki ∎