tsgo typechecks slower than TS6

[XiNiHa]

Against the same code, tsgo typechecks 5x+ slower than TS6.

Repro: https://github.com/XiNiHa/kysely-tsgo-slower

[ahejlsberg]

This is caused by #3445, which is a change from TS6. TS6 often bails out early of analyzing type relationships because it thinks it is dealing with an infinitely expanding type. TS7 is better able to recognize non-recursive types and therefore goes deeper in its analysis. That's what's happening here. Specifically, TS6 performs 601,143 type instantiations when compiling your repro, whereas TS7 performs 9,795,115 because of the deeper analysis.

I haven't deeply looked at the actual types in question. I wouldn't be surprised if they can be simplified to reduce the number of instantiations.

[XiNiHa]

Do you mean the behavior is expected/intended? Should it be fixed from the library side?

[ahejlsberg]

Iha Shin (신의하) (@XiNiHa) Yes, the behavior is expected. TS6 would similarly slow down if the changes in #3445 were applied to that codebase. The core problem is the complexity and expense of the types.

[igalklebanov]

Hey Anders Hejlsberg (@ahejlsberg) 👋

Sorry if commenting on closed issues is against guidelines. 🙏

The example contains userland complexity kysely does not promote (I have double-checked our documentation just in case), but also cannot deny. We've been on the receiving end of such examples for years, and have usually found ways to cut down on users' type-level costs without having to change anything on our end.

We always explore ways of simplifying/improving the type performance of our APIs, but also have to balance things with usefulness, hence methods like $if for conditional selects exist.

Simplifying Iha Shin (신의하) (@XiNiHa)'s helper function to:

function forQb<TValue, TInQueryBuilder, TOutQueryBuilder>(
  qb: TInQueryBuilder,
  collection: Iterable<TValue>,
  callback: (qb: TInQueryBuilder, value: TValue) => TOutQueryBuilder,
): TOutQueryBuilder {
  let result = qb as unknown as TOutQueryBuilder;

  for (const value of collection) {
    result = callback(result as never, value);
  }

  return result;
}

Makes TypeScript@^6 drop insantiations to 71,311 and TypeScript@^7 drop instantiations to 70,692, without losing on type-safety if the codebase has a single Database interface anyway. Significantly cheaper than the original.

While adding back Database interface comparison/pinning, but using a cheaper "container-for-Database" type that SelectQueryBuilder extends in the core:

function forQb<
  TValue,
  TInQueryBuilder extends OrderByInterface<Database, any, any>,
  TOutQueryBuilder extends OrderByInterface<Database, any, any>,
>(
  qb: TInQueryBuilder,
  collection: Iterable<TValue>,
  callback: (qb: TInQueryBuilder, value: TValue) => TOutQueryBuilder,
): TOutQueryBuilder {
  let result = qb as unknown as TOutQueryBuilder;

  for (const value of collection) {
    result = callback(result as never, value);
  }

  return result as never;
}

Makes TypeScript^6 drop instantiations to 72,903 and TypeScript@^7 drop instantiations to 72,318. Slightly higher than previous simplification, but still significantly cheaper than the original.

My understanding is that maybe we need to expose and promote usage of a dumb container type for SelectQueryBuilder's generics so that users match against it and not against SelectQueryBuilder itself.

[koskimas]

Iha Shin (신의하) (@XiNiHa) I'm working on a fix for Kysely, that will make typescript 7 about 5x faster than typescript 6 as one would expect for this and many other similar cases. I was able to remove the infinite recursion from the types. Follow kysely-org/kysely#1947 for progress.