Slow application when using hundrets of components, other ways of encapsulation?

@forstjiri

to cut the page into many smaller components, so for the grid, that would be 120 TileComponents

For now, the compromise seems to be to define an array filled with Data Transfer Objects and in for loop render block, but it doesn't solve isolation as nicely as the component.

It seems you have one component repeatedly rendered in one page. There are two ways how to achieve this.

a) One approach is create approx. 120 instances of one component and render each of it (Multiplier?)

b) The other possibility is to have one instance of this component and render it in {foreach} in template repeatedly and for every single rendering supply the component proper data via passing parameters.

sample code to explain the idea:

{$foreach $products as $product}
    {control 'productControl', product: $product}
{/foreach}

class ProductControl extends UI\Control
{

	public function render(ActiveRow  $product)
    {
		$this->template->product = $product;

        $this->template->render(__DIR__.'productView.latte');
    }
}

This may help to reduce the server overload.

Thanks for the answers, here is the example repo: (not our actual code but simplified so the problem is visible)
https://bitbucket.org/…/src/master/

I cannot use lazyloading in this case. I tried profiling and it seemed that Control::render was the bottleneck.

Having the render method with argument of active row helped a little.

Creation of hundreds components should add only few ms overhead by itself. Even from my simple test when adding 500 components it raised from about ~3ms to ~30ms which may not seem like a lot in absolute numbers but it matters a lot to us.

My summary is that Components cannot be used in such numbers for performance heavy projects.

I had an use case where we I was working on “activity stream”. Under the hood it was simple grid component which handled filtering, signals and other interactivity stuff (collapse/expand, show edit form, toggle status, etc.), but it had separate (nested component) Renderer to render feed entries.

So instead of multiple components There was only one. And instead of subcomponents I was importing template with {define} blocks.
If you use similar technique, probably it will be enough also for your use case (I would really like to see the perf test result). This is how it may look like:

class Renderer extends Control
{
  private bool $init = false;

  private function initRenderer(): void {
    $this->init = true;
    // init globally used rendering related stuff
    $this->template->setFile(__DIR__ . '/Renderer.latte');
	// etc.
  }

  public function render(Entity $entity) {
    !$this->init && $this->initRenderer();
	$tpl = $this->template;
	// set specific params if needed...
    $tpl->setParameters([
      'entity' => $entity,
    ]);
    $tpl->render();
  }
}

Renderer.latte

{import '@blocks.latte'}

{include #header entity: $entity}
{include #main entity: $entity}
{include #footer entity: $entity}

@blocks.latte

{define header}...{/define}
{define main}...{/define}
{define footer}...{/define}

Last edited by mskocik (2023-10-31 12:11)

@mystik Reinicialization of latte is about half of the overhead of what i tried.

@mskocik Yes, working with blocks instead of components is much much faster. But the block in your initRenderer does nothing.

@MarekBartoš I ran the tests on our staging and on my copy at once with command
hey -n 100 -q 5 -c 4 https://www.0.devklarka.cz/panske-tenisky | grep -E 'Fastest|Total'
And also looked at tracy time for confirmation. For what i tried render is about half of the overhead (base ~200ms, with template reiinicialization: +~130ms vs with just one template instance: +~60ms)

Last edited by forstjiri (2023-11-02 09:41)