Using maps to save data in type-metadata.storage.ts would result in a giant performance boost on app startup

[rezoled]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

In a large GQL application with 100s of schemas the bootstrap time for the Nest app is extremely slow.
This is caused mainly because of type-metadata.storage.ts which stores all the metadata in flat arrays.

On app startup, the class iterates over every GQL annotated class, and its fields, methods, their arguments and so on. Since all of the metadata is saved in arrays, this causes multiple iterations over each array with multiple levels of nesting.

Example: For a project with 100 GQL classes, with each 50 fields and methods (5,000 fields total), and 10 arguments per class (1,000 total), the recursion is as follows: 100 * 5,000 * 1,000 = 500,000,000

Describe the solution you'd like

Changing the data store models to Maps would result in O(1) access which would greatly optimize the startup time

Teachability, documentation, adoption, migration strategy

No response

What is the motivation / use case for changing the behavior?

Faster NestJS bootstrap time on large GQL projects

[kamilmysliwiec]

Just to make sure that I'm following: are you suggesting replacing arrays with maps which contain arrays so in methods like these:

• https://github.dev/nestjs/graphql/blob/da8c23ac915cdfc2cebffe0cf38921301a7bb246/packages/graphql/lib/schema-builder/storages/type-metadata.storage.ts#L88
• https://github.dev/nestjs/graphql/blob/da8c23ac915cdfc2cebffe0cf38921301a7bb246/packages/graphql/lib/schema-builder/storages/type-metadata.storage.ts#L102
• https://github.dev/nestjs/graphql/blob/da8c23ac915cdfc2cebffe0cf38921301a7bb246/packages/graphql/lib/schema-builder/storages/type-metadata.storage.ts#L116

we could use, for example, interfaces[target] (or .get(target)) instead o using the find() method? If so, I'm all in for this change. The reason we've been using arrays is that we had to stay compatible with the type-graphql library (see comment at the top of the class declaration) which is no longer the case.

[rezoled]

Exactly. I'd be happy to create a PR for that!

[kamilmysliwiec]

Feel free to do so! 🙌

[rezoled]

I created a PR with my public profile: #2212

[kamilmysliwiec]

Let's track this here #2212