Problem/Motivation
#2976148: Layout-based entity rendering should delegate to the correct section storage instead of hardcoding to either defaults or overrides changed how Layout Builder prevents infinite recursion when rendering FieldBlocks.
Before, it prevented any of the LB rendering code from running.
Now it only prevents any infinite recursion from occurring.
However, this means that all of the LB rendering code is running for each FieldBlock, even though it will never result in any real changes to the output.
Proposed resolution
Move the code from isLayoutBuilderEnabled()
to buildMultiple()
Remaining tasks
N/A
User interface changes
N/A
API changes
N/A
Data model changes
N/A
Release notes snippet
N/A
Comment | File | Size | Author |
---|---|---|---|
#14 | 3023220-recursion-13-interdiff.txt | 4.18 KB | tim.plunkett |
#14 | 3023220-recursion-13.patch | 3.6 KB | tim.plunkett |
#7 | 3023220-recursion-7.patch | 3.41 KB | tim.plunkett |
#3 | 3023220-recursion-3-interdiff.txt | 3.2 KB | tim.plunkett |
#3 | 3023220-recursion-3.patch | 3.32 KB | tim.plunkett |
Comments
Comment #2
tim.plunkettComment #3
tim.plunkettNo need to move the check, it can be done in both places.
Also codified it better as a method.
Comment #4
phenaproximaThis doc comment doesn't really match the method name. I think we should change it to something more descriptive. Perhaps "Determines if this display can be rendered without causing infinite recursion"?
This seems sneaky to me. Couldn't this be tested by calling the public isLayoutBuilderEnabled() and buildMultiple() methods instead, to more closely test the way that actual run-time code will interact with the class?
Comment #6
tim.plunkettComment #7
tim.plunkettDoes not address #4 yet, just a reroll.
Comment #8
tim.plunkettBumping to critical per #3054042-11: Views performance regression related to renders
Comment #9
andyg5000Thanks @tim.plunkett. Let me know if you need me to provide any more profiling data to get to the bottom of this one!
Comment #10
andyg5000Big improvement (as mentioned in slack). From 25+ seconds to 50 milliseconds
Before:
https://blackfire.io/profiles/62be7e91-f22f-49e5-98bf-a5b746e737ba/graph...()
After:
https://blackfire.io/profiles/11d5cdd0-cbe3-466a-982c-13793cdf3b66/graph...()
Comment #12
tim.plunkettThe above may have been affected by render caching.
Here's a fresh one from @andyg5000, deep linked to the LB part
Before: 29.4 s
After: 2.69 s
Comment #13
xjmComment #14
tim.plunkettAddresses #4
Comment #15
dawehnerI'm wondering why this code is not using
isLayoutBuilderEnabled
instead? Why shouldbuildMultiple
still run even$this->getThirdPartySetting('layout_builder', 'enabled')
is FALSE? I must miss something obvious.Comment #16
Berdir@dawehner: Apparently that's exactly what #2976148: Layout-based entity rendering should delegate to the correct section storage instead of hardcoding to either defaults or overrides removed, a bit confused too but I also didn't read through that issue.
Comment #17
tim.plunkettTL;DR is: because contrib can do their own thing
Comment #18
bkosbornePatch looks good & makes sense. Confirmed to solve this major perf issue for me. In my case I was not using field blocks that was causing the problem, but instead I was having issue with views output that was rendering the results using the _custom view mode (AKA rendered individual field output instead of rendered entity).
Comment #19
tim.plunkettClarifying title
Comment #20
xjmJust wanted to call out #10 again:
Comment #21
catchCommitted 44ffb27 and pushed to 8.8.x, cherry-picked to 8.7.x. Thanks!