Problem/Motivation
In my project, there is a content with 600+ (root-level) paragraphs item. With the changes from #3611607: Provide more info to component add buttons to help their customization, we were able to reduce the load time of this content item's edit page from 40-50sec to 7-8sec, but then my teammate's, @herved's analysis also revealed that LayoutParagraphsLayout spends too much effort on loading paragraph entities from storage again and again.
After applying the optimization of the MR of this ticket, edit page load time was reduced drastically, to 2.2-2.4sec.
Proposed resolution
Cache entities loaded from the field managed by LPL locally.
Remaining tasks
Nothing.
User interface changes
Nothing.
API changes
Nothing.
Data model changes
Nothing.
Issue fork layout_paragraphs-3611711
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
huzookaComment #4
huzookaComment #5
huzookaComment #6
huzookaComment #7
claudiu.cristeaThank you. This looks good to go
Comment #8
alorencI have noticed the following warning
Deprecated function: Using null as an array offset is deprecated, use an empty string instead in Drupal\\layout_paragraphs\\LayoutParagraphsLayout->getComponentByUuid() (line 322 of /var/www/html/web/modules/contrib/layout_paragraphs/src/LayoutParagraphsLayout.php
Comment #9
alorencComment #10
huzookaMaybe it looks weird, but now I'm approving the fix of my colleague, not my entire MR.
Comment #12
tiago commentedI found a bug in the MR that can write to or delete the wrong paragraph, so I pushed a fix and a test to the MR and I'm setting this back to Needs review.
getComponentDeltaByUuid()returns the position of the paragraph ingetEntities(), butgetEntities()leaves out field items whose paragraph cannot be loaded (for example a reference to a deleted revision). After such an item every position is one lower than the real field delta, sosetComponent()overwrites the previous paragraph anddeleteComponent()removes it. On 3.0.x without the MR this does not happen, because the old loop walked the field items.The fix keeps the field delta of each paragraph while building the cache, from the keys of
referencedEntities(), which are the field deltas. With duplicate UUIDs it keeps the first one, as the old loops did.ComponentDeltaTestputs an unresolvable reference first and checkssetComponent()anddeleteComponent(); it fails on the MR before the fix and passes on 3.0.x and on the MR with the fix. All Kernel tests pass with the MR merged into the current 3.0.x, including the translation tests from #3305070.I also measured the MR against the current 3.0.x (
ae8c8f4), on pages with two-column sections holding four text paragraphs each, as an admin (DDEV on macOS, PHP 8.3 with opcache, MariaDB 11.8, Drupal 11.4.8; each value is the mean of two interleaved rounds, each round the median of 9 requests or 15 calls).Opening the node edit form with the builder:
reorderComponents()with the full order:So the MR takes a 400 paragraph page from 11.2 s to 0.6 s, and the fix costs nothing measurable.