Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Memory usage on Symfony Form #29055

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

Closed
mixo opened this issue Nov 1, 2018 · 5 comments
Closed

Memory usage on Symfony Form #29055

mixo opened this issue Nov 1, 2018 · 5 comments

Comments

@mixo
Copy link

mixo commented Nov 1, 2018

Hello. How to reduce the memory usage on Symfony Form?
A form can use more then 128 MB, if I build a form with many fields and then render its. For example a form with 500 fields (a form with multiple embedded forms). Such form uses about 12 MB.
Every invoke the add method of the FormBuilder class uses about 16KB.

@Tobion
Copy link
Contributor

Tobion commented Nov 1, 2018

Do you the symfony frameworkbundle with it's form caching? Or a custom integration of the form component?

@mixo
Copy link
Author

mixo commented Nov 1, 2018

I use symfony framework, not custom integration.

But even if I use without the framework:

require __DIR__.'/../vendor/autoload.php';

use Symfony\Component\Form\Forms;
use Symfony\Component\Form\Extension\Core\Type\TextType;

$formFactory = Forms::createFormFactoryBuilder()->getFormFactory();

$a = memory_get_usage();
$form = $formFactory->createBuilder()
    ->add('task', TextType::class)
    ->add('task2', TextType::class)
    ->getForm();
$b = memory_get_usage();

var_dump($b - $a);

Every field uses about 5.4 KB

@xabbuh
Copy link
Member

xabbuh commented Nov 1, 2018

I don't think there is much we can do. The Form component is complex due to how forms can be built, extended and modified. This does not mean that there isn't room for improvement, but on a first glance the numbers you have here don't look too bad.

nicolas-grekas added a commit that referenced this issue Nov 10, 2018
…s (yceruto)

This PR was merged into the 4.2-dev branch.

Discussion
----------

[OptionsResolver] Micro optimizations and simplifications

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #29055
| License       | MIT
| Doc PR        | -

As we know, this component has a big impact on the workflow of the `Form` component. I'm a newcomer in Blackfire, so there could be other optimizations that I can't able to see, but here we go.

For now, we've less code to maintain ![commit-changes](https://user-images.githubusercontent.com/2028198/47917083-c3619d00-de7e-11e8-826a-0c3009948d93.png) and a micro-optimizacion of performance. It'd be great if someone could try these changes in a real project to see their real value.

![orbf](https://user-images.githubusercontent.com/2028198/47915644-e2116500-de79-11e8-8648-a5e619fcd3eb.png)
![metrics](https://user-images.githubusercontent.com/2028198/47917598-61a23280-de80-11e8-9153-3ea60317f1a5.png)

https://blackfire.io/profiles/compare/a04a13d3-7f60-4434-a2b8-0762efb8fbd6/graph
https://github.com/yceruto/orbf The sample takes into account only the core extensions.

Cheers!

Commits
-------

24c2213 Optimizations and simplifications OMG Blackfire!
@ro0NL
Copy link
Contributor

ro0NL commented Nov 26, 2018

@alexey-okhorzin did #29065 help?

@xabbuh
Copy link
Member

xabbuh commented Dec 4, 2018

Let's close here as there is no ad-hoc solution, but we can always consider to improve parts of the framework if someone proposes a more performant solution.

@xabbuh xabbuh closed this as completed Dec 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants