Feat: Performance enhancements#281
Conversation
|
@fveracoechea is attempting to deploy a commit to the cva Team on Vercel. A member of the Team first needs to authorize it. |
fveracoechea
changed the title
|
This is super thoughtful of you, thanks @fveracoechea 🙏❤️ Fairly busy at the moment and this will take some time to review, so don't be too disheartened if it takes some time to get around to this! Really appreciate it |
|
Thanks @joe-bell 🙏 let me know if you have any suggestions or concerns, I’d be happy to help! |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Hey @fveracoechea, just wanted to give you a quick update rather than leave you in the dark here! I'm starting to pick up For now, I'm going to hold off merging this simply because it's a little easier to work with the code I'm familiar with That said, I'm keeping this PR open as I don't want to discourage you from introducing your improvements – which are incredibly valuable! I'll keep you posted on |
|
Thanks @joe-bell, I appreciate the update, it totally makes sense, I'll be happy to revisit it when the timing works better. |
|
New, updated, and removed dependencies detected. Learn more about Socket for GitHub ↗︎
🚮 Removed packages: npm/react@18.2.0, npm/sharp@0.33.5 |
There was a problem hiding this comment.
I'd like to mention, this file is just for benchmarking purposes, basically making sure these changes are actually faster, could be removed before merging.
|
cva is really really slow in large codebase... (kudos for making this library nonetheless ❤️ 🙌 ) 
|
|
@fveracoechea are you using your own fork ? is it published somewhere ? up-to-date ? |
Hey @rvion, not at the moment, although you made a good point, the current implementation relies too much on object spread and array allocations that can add up pretty quickly on react apps. My main use case for CVA is when I use shadcn components which already implement CVA, I guess that's why I have not thought about doing my own fork, also I've been able to mitigate some of these problems by using react-compiler. |
|
Hopefully on a newer version (v1.0) will land with these perf changes applied. I really like the project and just like you @fveracoechea I'm also using shadcn/ui as the main design system base, but noticed on the Profiler (render) that it takes a small hit on screens that are too complex. Anywho, thanks for this amazing project @joe-bell! |
| function mergeDefaultsAndProps< | ||
| V extends CVAVariantShape, | ||
| P extends Record<PropertyKey, unknown>, | ||
| D extends CVAVariantSchema<V>, | ||
| >(props: P = {} as P, defaults: D = {} as D) { | ||
| const result: Record<PropertyKey, unknown> = { ...defaults }; | ||
|
|
||
| for (const key in props) { | ||
| if (!isKeyOf(props, key)) continue; | ||
| const value = props[key]; | ||
| if (typeof value !== "undefined") result[key] = value; | ||
| } | ||
|
|
||
| return result as Record<keyof V, NonNullable<ClassValue>>; | ||
| } |
There was a problem hiding this comment.
for...in already gives you the object’s enumerable keys, I might be missing something but I believe you can safely skip the if (!isKeyOf(props, key)) continue; statement
I ran a benchmark without it and this function ends up 11.8% Faster
┌───┬────────────────────────┬─────────────┬────────┬──────────┐
│ │ name │ ops/sec │ margin │ samples │
├───┼────────────────────────┼─────────────┼────────┼──────────┤
│ 0 │ original │ 13375270.00 │ 0.46% │ 13375270 │
│ 1 │ withoutIsKeyOf │ 15148843.49 │ 0.54% │ 15148845 │
└───┴────────────────────────┴─────────────┴────────┴──────────┘
There was a problem hiding this comment.
Interesting observation @thadeucity I've always checked keys when doing for-in loops, it has something to do with the object prototype, here is what I found on google
In this case, it looks like Object.keys() could be used and still get better performance from the loop, it'd be interesting to see if this is faster:
for (const key in Object.keys(props)) {
const value = props[key];
if (typeof value !== "undefined") result[key] = value;
}There was a problem hiding this comment.
Thanks for the clarification @fveracoechea , that makes sense!
I honestly did not know that detail about for...in iterating over enumerable properties from the prototype chain as well.
I’ll update the implementation and benchmark the overall impact a bit more broadly across the project, instead of looking at this function in isolation.
I also have another idea, in this very specific scenario, manually cloning the object might shave off a few extra nanoseconds.
There was a problem hiding this comment.
@fveracoechea
I just tested both scenarios, but both are slower than the solution you proposed.
The funny part is that, when tested in isolation, both the manual clone and the for (const key in Object.keys(props)) were slightly faster. However, when tested within the full library, both ended up being slightly slower.
7 participants
Description
Implement code optimizations on CVA to increase execution speed and reduce the number of operations, such as iterations and object copying.
Additional context
Let's say we have a web page made of React components, where most components utilize CVA.
Since React components render and re-render often, it's important to keep CVA's runtime overhead as low as possible. This optimization will enhance scalability, especially on large projects.
Benchmark results
All tests passing with no problems:
What is the purpose of this pull request?
Before submitting the PR, please make sure you do the following
fixes #123).