Cold start performance improvements - #20427
Conversation
|
Greptile encountered an error while reviewing this PR. Please reach out to support@greptile.com for assistance and include this reference: |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. WalkthroughAdded cached state for variant ordering in the design system. 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Hi guys, thanks for you great work!
I work on performance improvements on https://github.com/schoero/eslint-plugin-better-tailwindcss project. Part of issues can be fixed on the tailwind side only.
This is a first fix, I have a bigger one in mind, it would require a small additional public API method - out of scope of this PR.
Please let me know what you think.
Finding
getVariantOrder()re-sorts all parsed variants with the (expensive) variant comparator on every call, and it is called by every compileCandidates() invocation — per build pass, per @apply substitution, and hundreds of times during candidate canonicalization via the variant signature caches. Since parsedVariants is append-only, the computed order only changes when a new variant is parsed, so we can cache the result and invalidate on parsedVariants.size. This makes cold canonicalization (IntelliSense, lint plugins) faster and removes repeated sorting from @apply substitution and incremental rebuilds.Test plan
Tested at https://github.com/smnbbrv/better-tailwindcss-bench . The relevant part is the
epbt-now / tw-patchedplugin cost (ms, cold run net of parse baseline)