GeezerVison

TypeScript Bot (@typescript-bot) test this
TypeScript Bot (@typescript-bot) run dt
TypeScript Bot (@typescript-bot) user test this

Heya Ryan Cavanaugh (@RyanCavanaugh), I've started to run the extended test suite on this PR at ade67c6. You can monitor the build here. It should now contribute to this PR's status checks.

Heya Ryan Cavanaugh (@RyanCavanaugh), I've started to run the parallelized community code test suite on this PR at ade67c6. You can monitor the build here. It should now contribute to this PR's status checks.

Heya Ryan Cavanaugh (@RyanCavanaugh), I've started to run the parallelized Definitely Typed test suite on this PR at ade67c6. You can monitor the build here. It should now contribute to this PR's status checks.

The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master.

I'm not sure, should I merge it? The failed tests don't look related to Array#flat.

Bannerets do you have time for a performance test? Otherwise I'd like to close the PR to keep the number of open PRs manageable.

I'm not sure what's the correct way to write synthetic performance tests for types (since I don't know when the compiler can perform caching, etc.). Is there a utility in the typescript repository for this?

For example, I wrote this generator:

$ cat gen.js
for (let i = 0; i < 4000; i++) {
  console.log(
`declare var arr1_${i}: ReadonlyArray<ReadonlyArray<(string | number)[]>[]>;
arr1_${i}.flat(3);
declare var arr2_${i}: ReadonlyArray<ReadonlyArray<number>[]>;
arr2_${i}.flat(2);
declare var arr3_${i}: ReadonlyArray<string[][][][][][]>;
arr3_${i}.flat(4);
declare var arr4_${i}: ReadonlyArray<number[][]>;
arr4_${i}.flat(2);
declare var arr5_${i}: ReadonlyArray<ReadonlyArray<ReadonlyArray<string[]>>>;
arr5_${i}.flat(3);`)
}
$ mv built built-new
$ git checkout 7f1df6e53e
$ npm run build
$ mv built built-old
$ node gen.js > ttest.ts
$ time node ./built-new/local/tsc.js --noEmit --lib es2019.array ttest.ts
       61.21 real        63.06 user         0.54 sys
$ time node ./built-old/local/tsc.js --noEmit --lib es2019.array ttest.ts
      115.83 real       117.41 user         0.89 sys

It shows the unbelievable 88% increase in performance (I've tried to run it multiple times).

I switched to object literal types instead of string/number because those are fresh on each usage. But with 4000 copies, master now runs out of memory! So I reduced the number to 2000 and observed a ratio that's even better than yours.

Before

real	0m19.253s
user	0m24.197s
sys	0m0.667s

After

real	0m9.005s
user	0m11.581s
sys	0m0.245s

gen.js

for (let i = 0; i < 4000; i++) {
  console.log(
`declare var arr1_${i}: ReadonlyArray<ReadonlyArray<{ a_${i}: number }[]>[]>;
arr1_${i}.flat(3);
declare var arr2_${i}: ReadonlyArray<ReadonlyArray<{ b_${i}: number }>[]>;
arr2_${i}.flat(2);
declare var arr3_${i}: ReadonlyArray<{ c_${i}: number }[][][][][][]>;
arr3_${i}.flat(4);
declare var arr4_${i}: ReadonlyArray<{ d_${i}: number }[][]>;
arr4_${i}.flat(2);
declare var arr5_${i}: ReadonlyArray<ReadonlyArray<ReadonlyArray<{ e_${i}: number }[]>>>;
arr5_${i}.flat(3);`)
}

The reason is probably that there are 8 overloads, with the shallower-array overloads near the bottom. Conditional type instantiation and overload resolution are both linear, but shallower arrays resolve first with the conditional type.

It could be also that conditional type instantiation is more efficient than overload resolution.

I re-ran with --diagnostics and noticed that subsequent runs of the old compiler are much faster. I averaged four runs (not because that's a magic number, but because that's how much patience I had) and the average is 9.15 vs 9.12. So I think actually the two are about the same.

I find it interesting that these typings

type FlatArray<Arr, Depth extends number> = {
    "done": Arr,
    "recur": Arr extends ReadonlyArray<infer InnerArr>
        ? FlatArray<InnerArr, [-1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20][Depth]>
        : Arr
}[Depth extends -1 ? "done" : "recur"];

use the recursive conditional type "trick" that circumvents the restrictions discussed in #26980 and was explicitly warned against by @ahejlsberg and similarly not given the seal of approval by @sandersn. I've used the sort of depth limiting being done here, but always with the understanding that this is murky territory where dragons and other things that go bump in the night reside, and never with the thought that such code would make it into anything standard.

So, uh, what's the story here? Should I turn in my badge and service weapon? Should internal affairs be brought in? Does anything make sense anymore? Thanks!

Joe Calzaretta (@jcalz) Ironically, this PR was authored by Nathan Shively-Sanders (@sandersn)... 😂