Inferring complex arguments is slow when used inside a generic function

[hayes]

Bug Report

🔎 Search Terms

performance, generic, inference, slow, prisma

🕗 Version & Regression Information

Reproduced in ts 4.1, 4.3, 4.4-beta a @next

Using prisma in the repro, which does not run on older versions.

⏯ Playground Link

This issue is easier to see through extended-diagnostics, so I have created a repo here with an example: https://github.com/hayes/prisma-ts-perf-issue

The issue depends on some large and complex type to be noticeable (I am using a small prisma client in the repro). This playground example is kinda large, and the difference is not as obvious or noticeable :
playground link

💻 Code

import { PrismaClient } from "./prisma-client";

function createField<Type extends string>(options: {
  type: Type;
  resolve: (db: PrismaClient) => unknown;
}) {}

// function createField(options: {
//   type: string;
//   resolve: (db: PrismaClient) => unknown;
// }) {}

createField({
  type: "Boolean",
  resolve: async (db) => {
    await db.user.findUnique({ where: { id: 1 } });
  },
});

🙁 Actual behavior

The un-commented version of the createField is somewhat un-responsive in vs-code. This issue becomes worse as the prisma client grows. The commented out version (without the generic) is very responsive, and completions are almost instant.

Running tsc with --extended-diagnostics produces these results (version with the generic is on the left). There are massive differences in Types, Instantiations, and Assignability cache size .

🙂 Expected behavior

The commented out version, and un-commented versions should have similar performance. I am guessing using the generic is causing us to miss out on some existing optimization that lets us not check the full prisma types. I am hoping there is a way to optimize this pattern. I've run into this a few times now. It's often not as noticeable because few objects have a type as complex as a prisma client.