We're having some serious Intellisense performance issues with v10
Hello. We have about ~30ish routers in
mergeRouters (we're working on changing this to a namespaced router) but we're having some serious performance issues (10s+ to open Intellisense in VSCode with extensions disabled). We've also confirmed that TypeScript gets slower the more routers we add.
Obviously this is expected, but we didn't think we'd run into this issue with 100+ procedures. We thought we'd be facing an issue like this with 2,000+. Any help on this would be appreciated. We'd be happy to send over an NDA and pay for help as well. Although I can always talk through what's going on here on Discord and add some traces if you feel it would be useful.
Btw this is in a monorepo configuration. I haven't yet tried isolating the package on its own and testing to see if the performance is any better. It's a very big project that powers our startup. Thanks.6 Replies
Some of our routes use tRPC OpenAPI btw, have not confirmed if that's the source of the slowdown. We also tried adding type annotations to the procedures but there was little to no performance improvement.
Here is a similar post that talks about exactly this: https://discord.com/channels/867764511159091230/1161320446722064385/1161320446722064385
it looks like this is a known issue and there's even a library to help with this: https://twitter.com/whizzaf/status/1683998923382304768
We're also using Zod. It looks like Zod has performance issues
we were able to narrow it down. it looks like the issue is with
trpc-openapi. seems like a massive bug. 200% performance degradation (from 400ms to 1200ms)
just kidding, it's also Zod. both Zod and trpc-openapi completely tank our performanceHey, yeah Zod is the root of all pain with tRPC, even trpc-openapi I believe consumes those types and in doing so would blow up the performance cost, though I'm not a use of that package personally
We do a lot of type mapping, and if we're mapping over deep and expensive types, the type mapping also becomes expensive
Zod produces much more complex types than you would assume
I recommend avoiding all the masking+merging types in zod. Omit, Pick, Exclude, and a bunch of others. That will make a huge difference
You can achieve the same as those much more cheaply by composing your zod objects from plain JS objects containing named zod types, which might get you back to just bearable levels. I'm fighting the same thing at work and honestly the solution for us is using less Zod
i'm thinking about just switching us to Typebox. have you tried other validation libraries?
We support quite a few! So definitely worth a shot
Unfortunately not a lot of good tooling for DX performance out there right now so it's hard to make a recommendation, but I'm pretty keen on some codegen approaches which essentially use normal TS types - you can't get more efficient than that
to anyone who is seeing this in the future, enable
disableSourceOfProjectReferenceRedirect and call it a day. you'll lose out on direct project references but at least now you'll be able to do your development because intellisense and autocomplete workI’ll try this on my work codebase and if it works might lead us to some future improvements