[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Optimize compile script on MSYS.
From: |
Peter Rosin |
Subject: |
Re: [PATCH] Optimize compile script on MSYS. |
Date: |
Mon, 16 Aug 2010 22:25:36 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 |
Den 2010-08-16 20:30 skrev Ralf Wildenhues:
> Hi Peter,
>
> [ output reordered to print new vs old ]
>
> * Peter Rosin wrote on Mon, Aug 16, 2010 at 01:59:13PM CEST:
>> time for file in `./filenames 20 / .cc`; do ./compile cl $file; done
>> real 0m9.781s
>> real 0m9.875s
>
>> time for file in `./filenames 20 / .cpp`; do ./compile cl $file; done
>> real 0m5.547s
>> real 0m9.906s
>
>> time ./compile cl `./filenames 20 / .cc`
>> real 0m5.218s
>> real 0m5.187s
>
>> time ./compile cl `./filenames 20 / .cpp`
>> real 0m0.734s
>> real 0m5.156s
>
> That's terrible. I mean, we are looking at more than 1000% overhead
> from the compile script in some cases. :-/
Forking is not fun on neither MSYS nor Cygwin...
>> To conclude, this shaves off 4-5 seconds when compiling 20 files with
>> absolute file names on MSYS. The cost when the new code isn't needed
>> seems negligible in comparison.
>
> This means that we should still recommend the .cpp extension I guess.
> Or try `-TP ' or `-TC ' in preference to `-Tp' and `-Tc' since that
> means less translation, unless the switches provoke false positives or
> so.
-TC/-Tc is usually not needed, since *.c is auto-detected and so
universal. -TP doesn't work if you are also specifying a library,
so can typically only be used together with -c. Given the possible
gain, it might be worth pursuing...
>> That said, don't expect too much from this as using absolute file
>> names is not really the common case...
>
> But with -I and -L absolute names are common. Luckily, in typical cases
> compilation happens a lot more often than linking.
MSYS recognizes -I/abs/dir so that is not converted on MSYS (same for
-L/abs/dir for that matter, but that is of no use to us since we need
to convert that to -LIBPATH:blabla which MSYS does not handle). Hmm,
maybe those are converted on their way into the compile script though?
That might depend on where the compile script lives. I don't know
the exact rulez for when MSYS argument conversion kicks in..
> We might want to pass $build system information from configure to
> 'compile' in order to avoid the uname fork. I meant to wait with
> this for a moment in which we'd need to start passing information
> in order to support more compilers in 'compile' anyway, not so sure
> any more now.
>
> Another idea would be to try to do file name translation manually in XSI
> shell; I'm not sure if it could be done without forking, nor whether we
> have all the information to do it correctly though.
I'd rather not go there. It's bad enough that we don't use
cygpath on everything for Cygwin (I think we should)...
>> Subject: [PATCH] Optimize compile script on MSYS.
>>
>> * lib/compile (func_file_conv): Add new argument 'lazy' which
>> takes an optional list of conversion types where the requested
>> conversion isn't needed.
>> (func_cl_wrapper): Take advantage of the above for cases where
>> MSYS is doing the conversion for us.
>> Suggested by Ralf Wildenhues.
>
> OK, thanks!
I've pushed and merged into master (other way around actually). I
know that I don't need to merge every time, but this way I know
that I won't be the one getting into merging trouble later :-)
And I don't know when I'm going to touch it the next time...
> I tend to eliminate duplicate initial ChangeLog entry lines in
> successive entries, but I don't mind much either way, so do as
> is convenient for you. Note that the git-merge-changelog driver
> may currently re-introduce such lines when rebasing, that's an
> open TODO item there.
If a patch gets left behind it's boring to change it, so I tend
to just keep it...
Cheers,
Peter