Re: A potential approach to making tests faster on Windows

[Stefan Beller <sbeller@google.com>]

On Fri, Apr 6, 2018 at 2:40 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Apr 03, 2018 at 06:00:05PM +0200, Johannes Schindelin wrote:
>
>> > But if we're at the point of creating custom C builtins for
>> > busybox/dash/etc, you should be able to create a primitive for "read
>> > this using buffered stdio, other processes be damned, and return one
>> > line at a time".
>>
>> Well, you know, I do not think that papering over the root cause will make
>> anything better. And the root cause is that we use a test framework
>> written in Unix shell.
>
> I'm not entirely convinced of this. My earlier numbers show that we
> spend a lot of time actually running Git. But that's not because we're
> written in shell, but because the stable interface to Git is running
> individual processes.
>
> So we can unit-test wildmatch or similar in a single C program, but I
> think we inherently need to run "git init" a lot of times.
>
> Now I think there's reason to doubt some of my numbers. I was counting
> exec's, and non-exec forks due to subshells, etc, may be important. So I
> claim only that I remain unconvinced that we are certain of the root
> cause.
>
> At any rate, I would be happy to see more study into this. If we can
> create a measurable speedup for an existing script, that might give us a
> blueprint for speeding up the whole suite.

The setup of each test is finicky, as we'd do different setups for each test
as we'd test different things. I once wondered if we'd want to have a
"ready made" directory that contains repositories in various states
that we can copy for each test and only need minimal adjustments
instead of writing the setup from scratch in each script.