This is a preliminary report, I'm hoping someone who knows the implementation can chime in.
I noticed a significant performance hit when rendering ui_patterns form slots.
Opening layout builder block settings forms that uses ui_patterns and slots can take a very long time (more than 60s in some scenarios).
I attached a PDF containing a request that takes 60s when opening the "configure" block form in layout builder on my project.
We can see more than 2M call counts in Drupal\Core\Plugin\Context\ContextDefinition.
Many seem to originate from uasort in \Drupal\ui_patterns\Element\ComponentFormBase::orderSources here (lines 439-444)
This can be reproduced to some extent with a clean setup.
With demo_umami it doesn't seem as bad as on my project but it is still enough to grasp the issue. Maybe it needs more content types/fields to really become a problem.
- Install umami: drush si demo_umami
- Enable ui_patterns modules: drush en ui_patterns ui_patterns_blocks ui_patterns_field_formatters ui_patterns_layouts ui_patterns_library ui_patterns_views
- Go to /admin/structure/types/manage/article/display/full/layout and add a UI patterns block with slots. Inject fields in those slots with [Entity] ➜ [Field].
- Profile the request when clicking "configure" for that block
Commenting out the uasort calls in ComponentFormBase::orderSources does improve performance and at least makes the system usable. However, based on the call counts, the performance issue appears to go beyond that.
Provide better steps to reproduce so the performance issue is obvious.
Investigate the root cause and determine the appropriate solution.
N/A
?
?
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | xhprof-with-MR-diff.pdf | 308.17 KB | herved |
| ui_patterns-performance_issue.pdf | 637.57 KB | herved |
Show commandsStart 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:
changes
Comments
Comment #2
herved commented- uasort
-- \Drupal\ui_patterns\SourcePluginBase::label
--- $this->getChoices()
Seems to trigger a lot of unnecessary trips to context handling and
\Drupal\Core\Plugin\Context\ContextHandler::filterPluginDefinitionsByContextsEventually it doesn't use any of those and fallbacks to last line in
\Drupal\ui_patterns\SourcePluginBase::labelStacktrace: https://gist.github.com/vever001/e5f5721be404e9d4ce931d6df3dc208f
Comment #3
just_like_good_vibesHello,
thank you for reporting. it seems we have an unfortunate side effect of a recent new feature.
we will fix that soon.
if you rollback to a version like 2.0.6 or before, would you confirm that slowness disappears please?
thank you
Comment #4
just_like_good_vibesComment #5
herved commentedHi @just_like_good_vibes, I'll have a look shortly and report back today, thanks.
Comment #6
herved commentedYes, rolling back to 2.0.6 significantly improves performance compared to 2.0.9.
The same LB configure form goes from around 13s on 2.0.9 to 2-3s on 2.0.6.
I assume it involves https://git.drupalcode.org/project/ui_patterns/-/commit/d873637649a833f9...
Comment #7
just_like_good_vibesThank you very much for taking the time to check. we will fix asap.
Comment #9
just_like_good_vibesHello, would you try this version please ?
Comment #10
herved commented- 2.0.9: 13.39s
- 2.0.9 + MR diff: 2.55s
- 2.0.6: 2.23s
This is definitely better, thanks.
OTOH this is on a fairly powerful machine where standard LB configure block form request takes only a ~80-100ms to load in comparison.
So the context handling of ui_patterns is still extremely expensive.
This is from
Drupal\ui_patterns\SourcePluginManager::getDefinitionsForPropTypeand below which takes ~90% of the total request time and the call counts below it seem a bit crazy.It does solve the immediate issue but I still believe that something should be done to further improve this. I did try to investigate but this is definitely not an easy implementation.
Comment #11
herved commentedHere is the xhprof export of 2.0.9 + MR diff
With xhprof, the request takes 9.6s and
SourcePluginManager::getDefinitionsForPropTypeand below takes 86%.Comment #12
just_like_good_vibesHello,
thank you for for your time.
about your remark " but I still believe that something should be done to further improve this", this will be addressed later.
Comment #14
just_like_good_vibes