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.

Command icon 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

huzooka created an issue. See original summary.

huzooka’s picture

Issue summary: View changes
huzooka’s picture

Issue summary: View changes
huzooka’s picture

Assigned: huzooka » Unassigned
Status: Active » Needs review
huzooka’s picture

claudiu.cristea’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +Performance

Thank you. This looks good to go

alorenc’s picture

Status: Reviewed & tested by the community » Needs work

I 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

alorenc’s picture

Status: Needs work » Needs review
huzooka’s picture

Status: Needs review » Reviewed & tested by the community

Maybe it looks weird, but now I'm approving the fix of my colleague, not my entire MR.

tiago made their first commit to this issue’s fork.

tiago’s picture

Status: Reviewed & tested by the community » Needs review

I 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 in getEntities(), but getEntities() 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, so setComponent() overwrites the previous paragraph and deleteComponent() 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. ComponentDeltaTest puts an unresolvable reference first and checks setComponent() and deleteComponent(); 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:

Paragraphs 3.0.x MR MR with the fix
10 67 ms 58 ms 57 ms
40 176 ms 91 ms 89 ms
80 513 ms 142 ms 145 ms
200 2767 ms 317 ms 316 ms
400 11224 ms 639 ms 623 ms

reorderComponents() with the full order:

Paragraphs 3.0.x MR MR with the fix
40 0.49 ms 0.11 ms 0.11 ms
80 1.48 ms 0.21 ms 0.22 ms
200 9.73 ms 0.54 ms 0.53 ms
400 34.9 ms 1.09 ms 1.04 ms

So the MR takes a 400 paragraph page from 11.2 s to 0.6 s, and the fix costs nothing measurable.

justin2pin made their first commit to this issue’s fork.