Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
Some people reported that the UI gets slow with lots of Paragraphs.
Proposed resolution
We need to investigate the situation and at least start to track it with a reference setup.
We should also figure out with profiling if we can skip major parts of the load.
Remaining tasks
Define reference case(s)
Profile
Improve
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | interdiff-2847110-12-14.txt | 1.05 KB | toncic |
| #14 | profile_ui_performance-2847110-14.patch | 15.26 KB | toncic |
| #12 | interdiff-2847110-11-12.txt | 9.69 KB | toncic |
| #12 | profile_ui_performance-2847110-12.patch | 15.26 KB | toncic |
| #12 | nested_paragraphs_case_3_with_patch.png | 60.86 KB | toncic |
Comments
Comment #2
miro_dietikerLet's have three reference cases. Each case NOT randomised, but with a fixed sequence.
1) 1 type with a text field and a total of 100 paragraphs added flat to the node. Text should be filled with repeating text so that there is actual content and not emptyness.
1.1) Default Mode Edit
1.2) Default Mode Closed
2) 3 types (text, images, account reference) with 100 paragraphs added flat.
2.1) Default Mode Edit
2.2) Default Mode Closed
3) Deep nested setup with text only as leaves. 10 top level containers, each with 3 levels of childrens with each 2 text paragraphs as leave. That's 10*2^3 = 80 leaves plus the nodes.
3.1) Default Mode Edit
3.2) Default Mode Closed
We need to implement these cases with preparation time separated, widget loading time separated, with a clearly defined state of the entity cache. I guess also measured once with cold caches.
And then, i would want to compare the performance also with an old version of Paragraphs to learn how much / if we degraded performance.
Comment #3
miro_dietikerAh, this means primarily adding this stuff through the ui, not the api, because we want to know how slow the ui is.
We might want to implement a pure api measure too, to understand how much overhead the ui adds, but that's less priority.
And yeah those are no tests. This should NOT be rerun on every testbot trigger, just from time to time intentionally.
Comment #4
miro_dietikerDiscussed with Berdir.
Let's create the mass of entities with API.
And only measure edit and adding 1 more somewhere.
Let's do this as separate project (sandbox) and use a BrowserTest.
The Test will write profiling data into a file for later display.
Comment #5
toncic CreditAttribution: toncic at MD Systems GmbH commentedI will try this one.
Comment #6
miro_dietikerPossible follow-up: Our profiling should also include viewing a node. This needs spec in more detail.
Comment #7
toncic CreditAttribution: toncic at MD Systems GmbH commentedCreate three different cases:
1) 1 type with a text field and a total of 100 paragraphs added flat to the node.
2) 3 types (text, images, account reference) with 100 paragraphs added flat.
3) Deep nested setup with text only as leaves.
Also created start function which recording time and connect with some markup.
Comment #8
toncic CreditAttribution: toncic at MD Systems GmbH commentedProviding screenshot.
We need to discuss how we want to display these value, for now I am using basic debug function.
Comment #9
miro_dietikerMost importantly, display them as deltas.
Comment #10
toncic CreditAttribution: toncic at MD Systems GmbH commentedFor now it is looking like this for nested paragraphs case:
Comment #11
toncic CreditAttribution: toncic at MD Systems GmbH commentedStep further, added content for case with nested paragraphs and changed displaying test result.
I figured out that we have problem with action buttons with huge number of paragraphs.
Comment #12
toncic CreditAttribution: toncic at MD Systems GmbH commentedAdded part for testing changing edit mode.
Take three screenshots for nested paragraphs case to see if spent time is similar every time when we run the test.
After that uploaded patch from #2673076: Investigate loading pattern of field_collection and again take three screenshots.
The creating time is double faster and now action buttons are working but very slowly.
Still need to fix some small stuff about displaying results.
Comment #13
miro_dietikerGreat progress! Finally we have a reference so we can measure effective speed and improvements (or worsening). No more "it is sooo slow" myths, but data.
Didn't yet review the patch, but we should document some aspects of the performance measure, so people understand how much ui and api performance can be expected with Paragraphs.
Comment #14
toncic CreditAttribution: toncic at MD Systems GmbH commentedSmall changes with markers, to make report more readable.
Comment #15
toncic CreditAttribution: toncic at MD Systems GmbH commentedAdded follow-up #2855229: Document result from UIPerfromance test.
Comment #16
miro_dietikerI think best is if we create a sandbox and add the module there. This is for local execution only i guess.
But let's wait for more opinions, i'll create after consent.
Results though (and how to test them) should be provided and documented in Paragraphs itself.
Comment #17
toncic CreditAttribution: toncic at MD Systems GmbH commented@Berdir is also agree with creating new project and move this module there.
Comment #18
miro_dietikerPlease update the issue to make it apply in this project. We will keep it as a sandbox.
Comment #20
toncic CreditAttribution: toncic at MD Systems GmbH commentedCommitted this just to initialize project. Still need review and discussion.