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 ∎


Reply via email to