Poor tsserver performance, intellisense takes at least 10 seconds to appear and high CPU usage

[Suniron]

My configuration:

• Bun 1.2.0
• Elysia 1.2.10
• Platform is Linux 5.15.153.1-microsoft-standard-WSL2 x86_64 x86_64
• Typescript of my project (nor vscode's) in 5.7.3

I have nearly 100 routes in my monorepo project (using Turborepo), freshly migrated from Node/express.

Since the migration, the developer experience is catastrophic, every intellisense suggestion/autocompletion takes more than 20 seconds: it's a nightmare 🥵.

I tried to put this config and explore the logs :

  "typescript.tsdk": "node_modules/typescript/lib",
  "typescript.tsserver.enableRegionDiagnostics": true,
  "typescript.tsserver.enableTracing": true,
  "typescript.tsserver.log": "normal"

As an example of the results, the slowness must be explained by the “semantic work”:

In addition, CPU usage is very high when loading intellisense (consumed by tsserver.js from node_modules), .ex :

I tried with the extensions disabled and without profile, as well as from another vscode (from the Insider version).

I assume this is a problem with type inference. I couldn't find best practices for performance in the documentation. I think this is a necessary part of the doc 💡.

Thanks in advance for your help in investigating my plight 🙏

[MatthewAry]

Could probably cross-post to the Eden project

[abhi-slash-git]

Same problem for us.

[MatthewAry]

We're now exploring generating typescript definition files to resolve our perf issues.

[SaltyAom]

Update for 1.3 should reduce type inference time down by around 51%

As for a workaround, I'd recommend separating Elysia modules that are not related to each other and sum up into one final instance; in the final instance if possible, not try to extend anything

If you're using Eden, using inference from all route can be a bit slow
As you mentioned that you have around 100 routes, you can try to use a part of each module to instantiate as a smaller part of Eden Treaty

For example, you have module a, b, c; instead of merging it all and put it into one treaty instance, you can try to create each treaty for each module

Another solution would to be precompile type definition before importing to treaty

Another solution would be wait for TypeScript Go to arrive

[kravetsone]

Update for 1.3 should reduce type inference time down by around 51%

As for a workaround, I'd recommend separating Elysia modules that are not related to each other and sum up into one final instance; in the final instance if possible, not try to extend anything

If you're using Eden, using inference from all route can be a bit slow As you mentioned that you have around 100 routes, you can try to use a part of each module to instantiate as a smaller part of Eden Treaty

For example, you have module a, b, c; instead of merging it all and put it into one treaty instance, you can try to create each treaty for each module

Another solution would to be precompile type definition before importing to treaty

Another solution would be wait for TypeScript Go to arrive

maybe we can deprecate eden treaty? I guess it more complex at typescript perfomance

eden fetch maybe a way better here

[mwstr]

I support deprecation of eden treaty. It feels harder to read and compose

The only problem for me is feature parity. As far as I know eden fetch does not accept generators as body

[kravetsone]

I support deprecation of eden treaty. It feels harder to read and compose

The only problem for me is feature parity. As far as I know eden fetch does not accept generators as body

Yea i thing about it a lot.

eden threaty is really harder for typescript so probably we should avoid it

[m50S79sM6SRNp8Jn]

Any traction on this issue?

[yas1nshah]

no progress?