[PATCH 01 of 14] tests: roll test-committer.t into test-commit.t

[Adrian Buehlmann]

On 2012-06-09 01:17, Martin Geisler wrote:
> Mads Kiilerich <mads at kiilerich.com> writes:
> 
>> Martin Geisler wrote, On 06/08/2012 06:07 PM:
>>> Adrian Buehlmann <adrian at cadifra.com> writes:
>>>
>>>> # HG changeset patch
>>>> # User Adrian Buehlmann <adrian at cadifra.com>
>>>> # Date 1339161065 -7200
>>>> # Node ID d62774e5fdbcf4dd9a170c2ee2efb4dbbc4d7ffc
>>>> # Parent  35292e67674593ae5a32572eaf7916ab3b09bcda
>>>> tests: roll test-committer.t into test-commit.t
>>> I would like to question whether this is a good idea.
>> ...
>>
>> I doubt there is any speed gain from merging tests as long as there is
>> no reuse. Running two test files instead of one is probably not more
>> expensive than a single hg / python invocation - I can't be bothered
>> to measure it.
> 
> It's not the amount of hg invocations that we should count: they will be
> the same if you just append two .t files into a single .t file.
> 
> Also, I was actually thinking that more test scripts can be beneficial
> when running them in parallel: the cores will have a better chance of
> all being utilized if the scripts are all small and fast.
> 
> What I'm saying is simply that if there is a test script that takes 10
> sec to run, then it's bad if that becomes the final script executed:
> there will be (on average) 5 sec where only one core is busy. It would
> have been better if there were 10 script taking 1 sec each since the
> workers could have kept grabbing these small scripts and kept the cores
> busy.
> 
> I normally run 20 jobs in parallel and that saturates my 4 cores (8 with
> hyperthreading). But at the end of hte test there is 20-30 seconds where
> only some cores are utilized and I believe this is because some tests
> are bigger and slower than others.

I think you've succeeded at convincing me, that the mergers I proposed
are dubious in a general sense, to say the least. Also, merging may
destroy existing structure, so it may be hard to go back if the idea of
merging is hard-proven not to be beneficial later. So let's error on the
safe side and preserve the existing structure we have.

Actually, I'm a bit sorry for having proposed this pile of mergers. I
think I was a bit careless. On a case by case basis, it might make sense
to merge a couple of smaller tests. But not as a general move. Thanks
Martin for speaking up on this.

I hereby do retract the mergers in this series. Not out of frustration,
but out of doubt.