[TwigComponent] Profiler, memory consumption

[alinceDev]

Hi,

ux/src/TwigComponent/src/DataCollector/TwigComponentDataCollector.php

Line 168 in b81fe2c

$this->data['renders'] = $renders;

I noticed that this line causes consumption of a lot of memory when the profiler is enabled, so we have to increase the php memory_limit.

Thanks

[smnandre]

Does your project use a lot of TwigComponent ?

[alinceDev]

Yes around 15. We use twig component as widget component.

And I noticed that it consume a lot when there is a form inside component

[smnandre]

15 is something I often did with no problem lie yours... so i feel the form may share some responsabilites there ?

[norkunas]

I also noticed memory hog when using to render for example Tree component with some levels when there are many nodes, so refactored with live component to load from db only based on expansion states.. but that still leaves possibility to open everything and then backend just eats all the memory because of many nested component rendering

[alinceDev]

With 1 component it consume around 20 Mo without form. I only query Elasticsearch then render results.
If I comment the line I mentioned I consume around 40 Mo.

[smnandre]

Could you see if one of those lines has a major impact ? I'd bet on the component.

I guess we could improve/limit what's store there

$renders[$renderId] = [
    'name' => $componentName,
    'class' => $componentClass,
    'is_embed' => $event->isEmbedded(),
    'input_props' => $mountedComponent->getInputProps(),
    'attributes' => $mountedComponent->getAttributes()->all(),
    'variables' => $event->getVariables(),
    'template_index' => $event->getTemplateIndex(),
    'component' => $mountedComponent->getComponent(),
    'depth' => \count($ongoingRenders),
    'children' => [],
    'render_start' => $profile[0],
];

ux/src/TwigComponent/src/DataCollector/TwigComponentDataCollector.php

Lines 121 to 132 in b81fe2c

	$renders[$renderId] = [
	'name' => $componentName,
	'class' => $componentClass,
	'is_embed' => $event->isEmbedded(),
	'input_props' => $mountedComponent->getInputProps(),
	'attributes' => $mountedComponent->getAttributes()->all(),
	'variables' => $event->getVariables(),
	'template_index' => $event->getTemplateIndex(),
	'component' => $mountedComponent->getComponent(),
	'depth' => \count($ongoingRenders),
	'children' => [],
	'render_start' => $profile[0],

[alinceDev]

Ok, in my test $mountedComponent->getComponent() takes only around 5Mo, but $event->getVariables() takes around 75 Mo.

I think there is something wrong here. All my components takes 64Mo here.

Edit: Oh ok, I see, this is the result of memory_get_usage(), the amount of memory for each component confused me

Maybe 'variables' => $event->getVariables(), is not needed here, I don't see where it is needed

[smnandre]

I kinda doubt the Component are the cause of those 64Mb... with no certitude but i don't see why (on there is no diff between the renders)

[alinceDev]

The performance metrics is showing that this is the profiler which takes 116Mo. If I read correctly the metrics, my code only takes 36 Mo here

So I don't know where to search.

In my last comment, I asked if 'variables' => $event->getVariables() is used anywhere, if this variable is needed.

[smnandre]

Could you comment it (or force an empty array) to see if that only can solve things ?

The variables are used for debug mainly, and to recreate the exact context a template has been rendered

[alinceDev]

Hi @smnandre,

An anonymous components has access to the parents variables when used in a template. For example in my <twig:Icon />
I can access to the form variable used outside.
I have multiple <twig:Icon /> called in a template so $event->getVariables collect all variables outside of the component for each component. Is it the expected behavior ?
Is there a way to exclude them like in twig {% include '....' only %}

Thanks

[smnandre]

@alinceDev are you sure it happens with single components like <twig:Icon /> ? It seems to me the context is set in the event only for embed component (twig:Icon foo </twig:icon>)

The PR should fix both cases, but it intrigues me

[alinceDev]

@smnandre yes, as you can see