My Windows build is much slower than Linux build. Any way to speed up?

[Norbert Thiebaud]

On Mon, Dec 23, 2013 at 9:15 AM, bjoern <bjoern.michaelsen at canonical.com> wrote:
> There isnt so much we can do about the first thing in a clean way. We can do
> something about the second thing, e.g.:
>
>  http://cgit.freedesktop.org/libreoffice/core/commit/?id=66a0713dc9c676182fcd7aa1e21f8dc25c05be5e

btw:
+ else
+ {
+ fprintf(stderr, "no magic for %s(%s) in %s\n", fn, src_relative, work_dir);
+ }
+ }
+ if(!rc)
+ {
+ puts(created_line);  <--  create_line is undefined here if we took
the else above
+ }

>
> - as noted in the comment above the touching of a file in cygwin took some
>   ~250ms -- interestingly, this is not CPU-bound. A simplistic approach thus
>   would be, to just allways overcommit the build by some factor and see if it
>   improves the build time (or the CPU load).

yep. I typically overcommit by at least 50%. for instance on my 8-core
Windows tinderbox I build with -j14
This is especially important as make 'leak' randomly some job-descriptor...

>
> Of course, the real issue is: what is this 250ms idle wait to touch a file from
> cygwin about? If we know that we can likely workaround it. Maybe its cygwin
> polling some network share for the cygwin->windows path mapping? So any
> detective work on that might help:

There is a proposed patch series on gnu make to use
spawn() instead of fork() on cygwin... this has received significant
push-back from cygwin maintainers
as they say that spwan() support on cygwin is flaky since not often used...

> - Can one make the delay go away by e.g. disabling network shares/virus
>   scanners/other services?

Yes, it has been reported on this ML, some time ago, that disabling
virus scanner for the lo build/source filenamespace is a big win

>
> Finally, Michael Stahl is considering moving gbuild to work on a native windows
> GNU make without the cygwin wrapper. But that likely is quite a bit of work.

yep, that would be.. the 'easy' case of building plain cxx could be handled
by generating vxproj file based on what is in gbuild's makefile in a
fairly straight forward fashion
The more involved part is to deal with all the other special case.
That would prolly require developing 'custom build rule' in a vstudio
fashion for all the corner cases
from lex/yacc to idlc, xsltproc  and all the l10n tooling....
A lot of work indeed, on a very despicable platform.. so unless a
Windows fan combined with a skilled dev take that up (and that is a
very rare combo),
it is quite unlikely

Norbert