spaghet
spaghet6mo ago

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
spaghet
spaghet6mo ago
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 performance
Nick
Nick6mo ago
Hey, 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
spaghet
spaghet6mo ago
i'm thinking about just switching us to Typebox. have you tried other validation libraries?
Nick
Nick6mo ago
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
spaghet
spaghet6mo ago
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 work
Nick
Nick6mo ago
I’ll try this on my work codebase and if it works might lead us to some future improvements