[MGNLPN-514] Improve performance of VariantAwareTitleColumnDefinition Created: 08/Dec/20  Updated: 04/Oct/21  Resolved: 05/Feb/21

Status: Closed
Project: Magnolia Personalization
Component/s: Pages
Affects Version/s: 2.0.4
Fix Version/s: 2.0.6

Type: Improvement Priority: Neutral
Reporter: Richard Gange Assignee: Mikaël Geljić
Resolution: Done Votes: 0
Labels: maintenance, performance
Remaining Estimate: Not Specified
Time Spent: 19m
Original Estimate: Not Specified

Issue Links:
Cloners
is cloned by MGNLPN-560 Further Improve performance of Varian... Closed
is cloned by MGNLUI-6510 ValueProviders are invoked twice init... Closed
Relates
causality
caused by MGNLPN-270 Show the variants icon in the page tr... Closed
relation
is related to MGNLADVCACHE-113 Improve variants detection in caching Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Sprint: Maintenance 39, Maintenance 40, Maintenance 41, Maintenance 42, Maintenance 43
Story Points: 5

 Description   

Problem: performance decrease; the scan to render the variants icons etc is very inefficient.

The proposal is to update line 106 of VariantAwareTitleColumnDefinition.

return variantManager.hasVariant(node) || variantManager.isVariant(node);

Temporary workaround: empty /personalization-pages/decorations/pages-app/apps/pages-app.yaml



 Comments   
Comment by Mikaël Geljić [ 13/Jan/21 ]

Provided patch was declined: no longer shows when a page has component variants.

Worth noting the visitor doesn't recurse endlessly, but only for a page's own areas/components (or any "different" node-types, as implemented so far), currently running further assessment of usage within M5/M6 UI framework.

Comment by Mikaël Geljić [ 15/Jan/21 ]

An update: M6 UI apps trigger double invocation of column's ValueProviders, caused by Vaadin's default drag-and-drop support. This can seemingly be worked around, UI ticket & PR incoming. This should at least get M6 apps loading times on par with M5 apps.

Meanwhile, I'll propose minor improvements to the PersonalizationDescendantsVisitor in this ticket still.

Comment by Federico Grilli [ 25/Jan/21 ]

Moving this to the next release, as 6.2.6 release time is approaching and the main issue has been taken care of at MGNLUI-6510

Comment by Thomas Duffey [ 09/Jun/21 ]

Is this actually done? We're experiencing major author UI performance issues and the profiler is pointing at this same class. On 2.0.7 of the module.

Generated at Mon Feb 12 06:38:23 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.