Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why does this library need so much memory? #184

Open
rubiii opened this issue Dec 19, 2024 · 2 comments
Open

Why does this library need so much memory? #184

rubiii opened this issue Dec 19, 2024 · 2 comments

Comments

@rubiii
Copy link
Contributor

rubiii commented Dec 19, 2024

Unfortunately I don't have an answer for you, but I have a simple testcase at rubiii/benchmark_vcf

There's only one commit to create the minimal Rails app and then this commit adding ViewComponent::Form, some performance benchmark tasks, benchmark libraries and a simple view.

Running the benchmark:memory task in production env, yields the following results:

Screenshot 2024-12-19 at 17 28 07

I'm not sure how or how much I can help with this. I could implement some performance benchmarks for you like the ViewComponent library recently did as a starting point to improve the situation maybe? Let me know what you think.

For reference: We have a rather complex ViewComponent rendering several other components which all render some form elements using ViewComponent::Form. We benchmarked memory usage rendering this component with and without ViewComponent::Form.
It comes down to 460.094k memsize, 460.094 allocated without ViewComponent::Form and 8.906M memsize, 8.905.693 allocated with ViewComponent::Form. That's 19.36x more according to the benchmark.

@Spone
Copy link
Collaborator

Spone commented Dec 19, 2024

I guess it needs more memory because each field instantiates a ViewComponent instead of calling a simple helper, but maybe there's more overhead than needed? Would love to see some more benchmarks.

Also, maybe we could provide some kind of "light mode" where some fields are rendered using the regular helpers and other with ViewComponents? In my projects, we usually override some fields but not all: the most basic ones (text_field etc.) could stay rendered the regular way.

@rubiii
Copy link
Contributor Author

rubiii commented Dec 19, 2024

@Spone You're probably right regarding our app. We've pretty much subclassed all form components and added mostly Tailwind classes via the html_class method and in some cases added templates to extend a component's markup. And that's our default form builder 🙃 It seems to really add up.

Edit: There's two other performance tasks included in that commit as well, benchmark:bm and benchmark:ips. Performance itself doesn't look too bad, but something needs a lot more memory compared to just using Rails Tag classes.

Edit2: I feel like since everyone who's following the README, generating the ViewComponent::Form FormBuilder, which renders all fields as components, is going to run into this sooner or later, we need to figure out what's causing this major overhead. I don't see how one would benefit from opting in to fields one by one or how that would help adoption, when the idea is to use the form components classes provided by this library. Or maybe that was not the idea?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants