What caused the performance issues for the `sap.ui.core.XMLComposite`

[dfenerski]

Hello,

as per this answer, "major performance issues" were the reason that got the sap.ui.core.XMLComposite class deprecated. Is it possible to shed a little more light on this? What exactly causes the issues, is usage of this control somewhat still safe if some guidelines are adhered?

Thanks

[dfenerski]

My use case: 1.96 OpenUI5 App; the XMLComposite control contains a big-ish sap.ui.layout.form.Form with a lot of inner dependencies between the FormElements

[nnaydenow]

Hello @dfenerski, Thank you for sharing this finding. I've created an internal incident 2280008843. The status of the issue will be updated here in GitHub. Regards, Nayden

[dfenerski]

Also, is it possible to utilize XMLTemplateProcessor manually in any way? perhaps for custom-controls? Sometimes it is really much more convenient to build an XML-Tree than to implement a render method.

[dfenerski]

Any info on this?

[codeworrior]

Well, it was not only about performance. But let’s start with that one:

Performance The main problem is with the ManagedObjectModel (MOM) which is used by the XMLComposite to connect its façade with the internals. The MOM introduces another layer of data binding (with two layers of events and listeners). When used in a fine-grained way (small composite controls), we observed a significant performance penalty through these additional layers. When used in a less fine-granular way, the performance of the MOM degrades, too as it installs many change listeners in larger control trees. This, btw, are not theoretical considerations. An early iteration of the sap.ui.mdc library (long before it went open source), heavily used XMLComposites and then ran into these issues. Most of the controls had to be re-implemented as “standard” composites to address the issues.

Synchronous Loading As the XMLComposite is a control and as controls in UI5 are created synchronously via constructor, the XMLComposite uses synchronous processing of the fragment to build its control tree. This does not work well with strong Content Security Policies (CSPs). Currently, library preloads address this, but we also try to stay CSP compatible in single requests scenarios (thinking into the direction of http2 / http3 and smaller, portioned bundles or for Hybrid container apps). Making the XMLComposite compliant with such scenarios either would result in async control tree creation (causing a bad flickering “Web 2.0” experience) or would require additional investment in some kind of an async construction mechanism (like we have it for views and fragments).

XMLView Caching The XMLComposite implements its dynamic aspects only after instantiating the control (as it loads the fragment only during construction to assign instance-specific IDs and as the MOM only works on controls). This prevents it from benefitting from the XMLView caching, which has to happen before controls are instantiated. As a result, the dynamic aspects have to be processed each time again, although in many cases (e.g. when based on model metadata) at least parts of it should be cacheable.

Complexity / Supportability Additionally, the XMLComposite together with the MOM introduces a complexity that is hard to handle for developers. It’s hard to understand what’s going on, it’s hard to debug.

So from our point of view, the XMLComposite has several pain points. For sure, we could invest in each of them and try to find solutions. But in sum, there have been too many topics (esp. taking our limited capacity into account). Plus, there are alternative approaches. Scenarios, that don’t require the complexity of the MOM can use fragments; the Fiori Elements stack V4 (aka sap.fe) introduced another approach called macros (or, meanwhile building blocks) that are resolved at templating time and therefore perfectly integrate with XMLView caching). We had many controversial discussions before deciding, as we’re well aware of the need for and the benefits of a declarative approach for composites. But the need for significant investments in multiple areas on the other side or the risk of getting many customer incidents if the XMLComposite is used "as is" more widely, together with the existence of established alternatives finally made us decide for the deprecation.

Last but not least, we hope to revisit the topic of declarative composites again in future, but maybe with a rather build-time centric approach.