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