[Form/Profiler] Massively reducing memory footprint of form profiling pages... #27923
Conversation
… pages by removing redundant 'form' variable from view variables.
There was a problem hiding this comment.
Tested in my project where I couldn't access the form profile due to the memory limit reached, thank you @VincentChalnot!
|
For 2.8? |
|
@xabbuh I never had this problem in Symfony 2.8 so I created this PR on the 3.4 branch but I can rebase on the 2.8 version if it can be backported to 3.4 after that. |
|
Great first contribution! |
|
Thank you @VincentChalnot. |
…m profiling pages... (VincentChalnot) This PR was merged into the 3.4 branch. Discussion ---------- [Form/Profiler] Massively reducing memory footprint of form profiling pages... … by removing redundant 'form' variable from view variables. | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | | License | MIT | Doc PR | ## Problem When trying to profile large forms in web profiler, the page can get so big that the memory footprint of the web browser excedes 1Gb making everything unusable and sometimes crashing the browser. This is especially true for "deep" forms as every node of the form also contains its children in the debugging infos. ## Solution When removing the "form" view variable that actually contains duplicated contents of everything already displayed in the page, the memory footprint massively decrease making the page usable again even form very complex and deep forms. By using CutStub, we keep a necessary level of information by providing the information that the variable is indeed here but not directly accessible in the dump. Commits ------- 5f5077f [Form/Profiler] Massively reducing memory footprint of form profiling pages by removing redundant 'form' variable from view variables.
|
@yceruto, @ogizanagi, @fabpot thank you for your kind words. |
|
Oups, there is an issue here: this turns |
|
I assumed it was already a mandatory dependency but I see that there is a hack in the FormDataCollector class to handle whether the VarDumper component exists or not... Do you need me to fix my PR? |
|
@yceruto @VincentChalnot can you please confirm #28037 also fixes the issue? |
…las-grekas) This PR was merged into the 3.4 branch. Discussion ---------- [Form] fix truncating form views in data collector | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | no (fixing a non released patch) | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - Fixes #27923. Commits ------- 5fa1f12 [Form] fix truncating form views in data collector
Improved Form event bubbling symfony/symfony#8834 (comment) Removing custom code fixed by symfony/symfony#27923
… by removing redundant 'form' variable from view variables.
Problem
When trying to profile large forms in web profiler, the page can get so big that the memory footprint of the web browser excedes 1Gb making everything unusable and sometimes crashing the browser.
This is especially true for "deep" forms as every node of the form also contains its children in the debugging infos.
Solution
When removing the "form" view variable that actually contains duplicated contents of everything already displayed in the page, the memory footprint massively decrease making the page usable again even form very complex and deep forms.
By using CutStub, we keep a necessary level of information by providing the information that the variable is indeed here but not directly accessible in the dump.