Performance: variance check balloons number of instantations and degrades performance

[andreialecu]

Bug Report

The Mongoose project recently introduced their own typescript types, therefore deprecating the DefinitelyTyped types.

However, the new types suffer from some big performance issues, greatly slowing down the VS Code developer experience. I've been investigating the problem and noticed that the issue seems to occur from some extends checks.

Related issues in mongoose repo:
Automattic/mongoose#10349
Automattic/mongoose#10487
Automattic/mongoose#10492

🔎 Search Terms

performance extends instantiations recursiveTypeRelatedTo

🕗 Version & Regression Information

This occurs on TS 4.3.5.

⏯ Playground Link

Unfortunately no playground link, but I made a very simple repro at: https://github.com/andreialecu/typescript-performance-extends

Take a look at the README there.

💻 Code

This diff in mongoose's types seems to completely eradicate the problem:

diff --git a/types/mongoose.d.ts b/types/mongoose.d.ts
index 9e0ad99..2fab5ff 100644
--- a/types/mongoose.d.ts
+++ b/types/mongoose.d.ts
@@ -1232,7 +1232,7 @@ declare module 'mongoose' {
   type PostMiddlewareFunction<ThisType, ResType = any> = (this: ThisType, res: ResType, next: (err?: CallbackError) => void) => void | Promise<void>;
   type ErrorHandlingMiddlewareFunction<ThisType, ResType = any> = (this: ThisType, err: NativeError, res: ResType, next: (err?: CallbackError) => void) => void;
 
-  class Schema<DocType = Document, M extends Model<DocType, any, any> = Model<any, any, any>, SchemaDefinitionType = undefined, TInstanceMethods = ExtractMethods<M>> extends events.EventEmitter {
+  class Schema<DocType = Document, M = Model<any, any, any>, SchemaDefinitionType = undefined, TInstanceMethods = any> extends events.EventEmitter {
     /**
      * Create a new schema
      */

The difference between before and after are:
Before:

Identifiers:                45586
Symbols:                    76446
Types:                      20569
Instantiations:             93884
Memory used:               93011K
Assignability cache size:    5146
Check time:                 0.67s

After:

Identifiers:                45582
Symbols:                    27736
Types:                        710
Instantiations:               818
Memory used:               59482K
Check time:                 0.03s

I realize the code after the diff isn't exactly equivalent, but the problem seems to be related to the extends check. Avoiding extends gets rid of the issue.

Here's a cpu profile:

cpuprofile.zip

The 'before' version shows:

🙁 Actual behavior

Slow type checking performance, especially in VS code.

🙂 Expected behavior

Better performance.

---

I opened this in the hope that there is value in investigating the repro by the TS team, in order to check whether any performance improvements in cases such as this one are possible.

[andreialecu]

Tagging @amcasey as per request in a comment in a similar thread about editor performance issues: #34801 (comment)

[andreialecu]

I stumbled upon https://www.npmjs.com/package/@amcasey/ts-analyze-trace which seems super useful. It should really be mentioned in the wiki page here: https://github.com/microsoft/TypeScript/wiki/Performance-Tracing

Here's the output on the repro above:

Hot Spots
└─ Check file /users/andreialecu/work/contrib/tsc-perf/index.ts (533ms)
   └─ Check variable declaration from (line 11, char 14) to (line 17, char 3) (529ms)
      └─ Check expression from (line 11, char 27) to (line 17, char 3) (529ms)
         └─ Determine variance of type 91 (513ms)
            └─ Compare types 104 and 103 (411ms)
               └─ Compare types 174 and 175 (380ms)
                  └─ Compare types 212 and 209 (378ms)
                     └─ Compare types 212 and 208 (372ms)
                        └─ Compare types 211 and 208 (372ms)
                           └─ Determine variance of type 183 (286ms)
                              └─ {"id":183,"kind":"GenericType","name":"Query","typeArguments":[184,185,186,187],"location":{"path":"/users/andreialecu/work/contrib/tsc-perf/types/mongoose.d.ts","line":2080,"char":3}}
                                 ├─ {"id":184,"kind":"TypeParameter","name":"ResultType","location":{"path":"/users/andreialecu/work/contrib/tsc-perf/types/mongoose.d.ts","line":2080,"char":15}}
                                 ├─ {"id":185,"kind":"TypeParameter","name":"DocType","location":{"path":"/users/andreialecu/work/contrib/tsc-perf/types/mongoose.d.ts","line":2080,"char":27}}
                                 ├─ {"id":186,"kind":"TypeParameter","name":"THelpers","location":{"path":"/users/andreialecu/work/contrib/tsc-perf/types/mongoose.d.ts","line":2080,"char":36}}
                                 └─ {"id":187,"kind":"TypeParameter","name":"RawDocType","location":{"path":"/users/andreialecu/work/contrib/tsc-perf/types/mongoose.d.ts","line":2080,"char":51}}

Seems that the hot spot is: Compare types 104 and 103. Types 104 and 103 are:

{"id":103,"symbolName":"Model","recursionId":77,"instantiatedType":91,"typeArguments":[41,93,94],"firstDeclaration":{"path":"/users/andreialecu/work/contrib/tsc-perf/types/mongoose.d.ts","start":{"line":757,"character":15},"end":{"line":757,"character":33}},"flags":["524288"]},
{"id":104,"symbolName":"Model","recursionId":77,"instantiatedType":91,"typeArguments":[42,93,94],"firstDeclaration":{"path":"/users/andreialecu/work/contrib/tsc-perf/types/mongoose.d.ts","start":{"line":757,"character":15},"end":{"line":757,"character":33}},"flags":["524288"]},

From what I can see the only difference is in the typeArguments, but types 41-43 show no relevant information. They're the only blank ones from types.json:

{"id":41,"flags":["262144"]},
{"id":42,"flags":["262144"]},
{"id":43,"flags":["262144"]},

[andreialecu]

An even simpler way to trigger this seems to be (grab mongoose.d.ts from: https://cdn.jsdelivr.net/npm/mongoose@5.13.5/index.d.ts):

import { Model } from "mongoose";
class Foo<T extends Model<any>> {} // add/remove the `extends` check and run `yarn tsc --extendedDiagnostics`
export const UserSchema = new Foo<Model<{}>>();

// with: class Foo<T> {}
Types:                         92
Instantiations:                 2

// with: class Foo<T extends Model<any>> {}
Types:                       42259
Instantiations:             291012

[sandersn]

As we discussed on discord, I think the problem is that structural assignability check is expensive, and the variance check is what triggers the structural assignability. It might be possible to skip variance checking in your specific case if the types were treated more nominally. I think the interesting question is whether production code would be able to avoid a variance check.

[andreialecu]

Thank you, @sandersn, for a very insightful discord discussion! 🙂

For reference, here's how the types would be used, idiomatically, using mongoose, as per the documentation: https://mongoosejs.com/docs/typescript.html

It's possible I'm overlooking something but I'm not sure if variance checking is necessary in this case, since the types are nominal here and a base interface for the "schema" would always be defined and used.

[andreialecu]

Hope you don't mind the ping @amcasey (and/or @weswigham)

I noticed this was tagged as planned for TD 4.5 but I was wondering if there's anything you could point us to in the mean time. (This has been an ongoing problem in mongoose and it has been making life painful for everyone since the types got moved off Definitely Typed.)

Improving typescript performance has been a priority for mongoose maintainers but seems that the root cause still can't be found. Any pointers would be hugely appreciated. Thank you!