automake-patches
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]