This CL shards the CFE try bot tests better.
* co19_2 runs was previously made faster, so using 10 shards on that is
way too much.
* sdk_test runs was previously made faster, so using 5 shard on that is
way too much.
* unit_tests was taking ~10 minutes and wasn't sharded. This CL shards
it. Note that this sharding is semi-complicated because a few tests
use git which is not usable on shard-runs. To overcome this a previous
CL renamed the tests that use git and here the sharded runs only run
the tests that doesn't require git. Then the "main bot" runs the tests
that require git.
* unit tests suites was taking ~12 minutes and wasn't sharded. This CL
shards it. Note that this sharding is semi-complicated because a few
of the suites use git which is not usable on shard-runs. Also a single
suite uses many more files that it is reasonable to include in the
fileset for the shards. In both cases these are run on the "main bot"
instead. The suit runnier was already "threaded", but simply launched
all threads (say around 20 or something like that) at the same time.
That's not ideal if having, say, 8 cores to work with (which is what
the bots seem to have) - or 12 (which is what my computer has).
Now only 'cores - 1' "threads" are run at any one time, and most
"sub-suites" are sharded, so that if one finishes early that core
can start another "sub-suite" - hopefully utilizing more of the
resources avaiable on the computer running it.
In total - in my 'benchmarks' (i.e. try bot runs) - the
front-end-linux-release-x64-try bot previously rook around 35 minutes
to complete, and with these changes it takes around 15 minutes to
complete. The biggest entry in the timeline is now building dart which
takes almost half that time. It does so with fewer shards than before,
but each might be utilized for longer.
Change-Id: Ie034058d8f33aafd21bc49f2bc878484563ba01c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/181383
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Output from a comparison could be something like
Integers differ: 2 vs 3
Map with key 'nullability' has different values (tag 95, likely 'TypeParameterType')
Lists have different values at index 0
Map with key 'items' has different values
Map with key 'typeArguments' has different values (tag 93, likely 'InterfaceType')
Map with key 'returnType' has different values (tag 3, likely 'FunctionNode')
Map with key 'value' has different values (tag 1, likely 'Something<1>')
Map with key 'function' has different values (tag 6, likely 'Procedure')
Lists have different values at index 0
Map with key 'items' has different values
Map with key 'procedures' has different values (tag 2, likely 'Class')
Lists have different values at index 6
Map with key 'items' has different values
Map with key 'classes' has different values
Lists have different values at index 458
Map with key 'libraries' has different values
Which should be read bottom up as something like
Component -> the 458th library -> the 6th class ->
the 0th procedure -> function -> returnType (a InterfaceType) ->
0th type argument (a TypeParameterType) ->
nullability has value 2 in one input and 3 in the other.
Change-Id: I49007a80ddb53a0ba1fae04b22d6efeae3687724
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/114602
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Jens Johansen