Views performance regression related to renders

Any clear differences in Blackfire profiles between the two versions that you see? Have you seen any way to reproduce this with just Drupal core? The symptoms are pretty clear but its hard to start looking for a culprit with only the symptoms.

I'm pretty sure this is caused by layout builder, you either weren't using that in 8.6 or it changed things and is now much slower.

90% of the execution time is in Validator::validate(), which is called by Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay.

Maybe the view was already uncacheable before (which you should investigate and try to fix), or maybe that validation is causing it to be uncacheable, which is why it happens on every request.

The thing is that you/views is just displaying a single field with viewField(), so all that complicated logic and context matching that it is doing is pointless and should IMHO not run there. So for a field-based view, it might be a relatively easy fix, but I'm pretty sure that this is also a massive overhead for a regular layout-based entity rendering. validate() is an *extremely* slow thing (to the point that we might need to re-evaluate if the symfony validator is the right thing for us, I'm not sure) and it should not have to run on view, not a full validation anyway. I think I've seen a similar issue somewhere already.

Yes, the current page doesn't matter, the entities that are being displayed in the view matter. So if it's also not enabled for those products, then that might be the specific reason for the regression, that 8.7 is doing that preparation also when it is not enabled.

Two extra seconds makes this critical.

Tagging as related, I opened it earlier today after spending a some time doing some intensive debugging, @Berdir believes these two issues are related and I agree, it looks like they both might lead to the same root problem.

Ok, this should help with calls coming through viewField() and \Drupal\views\Entity\Render\EntityFieldRenderer::buildFields(), looks like LayoutBuilderEntityViewDisplay doesn't itself check in buildMultiple() if it is enabled or not, the custom mode check already does existing in the method doing the check.

This will not address the bigger issue, but at least it will be limited to use cases that actually do use layer builder and not just having the module enabled :)

Possibly a dupe of #3023220: Performance: Prevent extra Layout Builder code from running when rendering fields in isolation (Views results, FieldBlock, etc)?

That does look very related yes, why are you only doing the custom check there though? Not sure if that would cover what \Drupal\views\Entity\Render\EntityFieldRenderer::buildFields is doing as it creates its own view display and doesn't specifiy a view mode. Not sure what the default value is then.

Default value is static::CUSTOM_MODE, so that should work just fine.
The above patch will fail tests, the one in the linked issue does not

Closing as a dupe of #3023220: Performance: Prevent extra Layout Builder code from running when rendering fields in isolation (Views results, FieldBlock, etc), bumped that to critical