With a cold cache xb/api/v0/config/component takes upwards of 5 seconds to load on my local environment
Profiling it with SPX I see 11.48 Million ‼️ function calls with a wall time of 8.77s
Improve the performance of this endpoint as the XB UI doesn't work until it has been loaded - we block loading the component and page data forms until it has finished.
Looks like some things we could optimise are in the shape matcher - \Drupal\experience_builder\ShapeMatcher\FieldForComponentSuggester::suggest in particular as the entry point
- Drupal\Core\Entity\TypedDat…tyDataDefinition::getBundles - 137k calls from \Drupal\experience_builder\ShapeMatcher\JsonSchemaFieldInstanceMatcher::findFieldInstanceFormatMatches
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
larowlan.
Comment #4
larowlanThis was causing cypress fails for me locally due to the time out.
MR improves performance by 80%
Comment #5
larowlanSalacious title update
Comment #6
wim leersYep, I knew this: #3515510-2: Improve backend API performance: add caching to shape matching 👈 that's why I moved it to the issue queue component :) This essentially does exactly what I intended 😃
Comment #7
wim leersThere's plenty more low-hanging fruit, see https://git.drupalcode.org/project/experience_builder/-/merge_requests/1....
There's also #3503038: Enable candidate `DynamicPropSource` suggestions for code components: refactor `GeneratedFieldExplicitInputUxComponentSourceBase` and `FieldForComponentSuggester` to need only SDC's ComponentMetadata, not SDC plugin instances to decouple this from SDCs.
But here's the real kicker: we don't need any of this until a
ContentTemplateUI exists! So I've been wanting to removedynamic_prop_sourcesfrom the/xb/api/v0/config/componentresponse for a good while. Which is why #3510896: Add a new internal HTTP API for candidate `DynamicPropSource`s to enable a `ContentTemplate` UI has been assigned to me for months. That will simply remove these computations from the critical path!Because the
ContentTemplateUI should be able to just request the candidate dynamic prop sources on a per-content entity-t bundle basis. There's never a need to list them all across all entity types/bundles — I did that only for early PoC/testing purposes!Comment #8
wim leersDone: #3510896-8: Add a new internal HTTP API for candidate `DynamicPropSource`s to enable a `ContentTemplate` UI.
Comment #9
wim leersComment #10
wim leersComment #12
wim leersNext performance improvement: #3510896-8: Add a new internal HTTP API for candidate `DynamicPropSource`s to enable a `ContentTemplate` UI.