Performance Problem with big Ui5 Apps using XMLViews

[dcwb89]

Why are you proposing this feature?

This ticket is not entirely a feature request, but rather an inquiry about what appears to be intentional behavior.

TL;DR:

• OpenUi5 app in version 136 with 150+ XML views
• Problem: views are being preserved by RenderManager and “polluting” the DOM to such an extent (~20k elements) that the app is hardly usable anymore due to very slow rendering
• Question: Is this desired/acceptable behavior for large apps, and if so, what is the recommendation to not experience such problems?

The whole story:
We have a fairly large OpenUi5 application with over 150 views, which we have recently been modernizing in preparation for OpenUi5 2.0.
The first steps were to replace all JSON views with XML views, upgrade the Ui5 version from 1.71 to 1.136, and start outsourcing parts of the UI to components. Recently, the following problem has arisen:
When a user navigates to many areas of the application, performance decreases over time. At a certain point, this makes the application unusable.
What we have found out about this:
Unlike JSON views, XML views use preserve logic, which places DOM elements in an invisible area for reuse. However, this area is never “cleaned up,” so more and more DOM elements accumulate over time. When the number of elements reaches a critical value (for us, approximately 20k so far), the problem described above occurs.
Since this problem only occurs in very large monolithic applications, I am unfortunately unable to provide an MRE. Therefore, I have the following questions:

1. Is the behavior described intentional or at least acceptable?
2. If so, is it possible (and sensible) to disable preserve or to clean up manually at certain times?
3. What is the expected number of DOM elements for applications structured according to best practice approaches?
4. What is the recommended approach for large applications to avoid such problems?

[ivoplashkov]

Hello @dcwb89 ,

Thank you for sharing this finding. I've created an internal incident DINC0681310. The status of the issue will be updated here in GitHub.

Regards,
Ivaylo

[boghyon]

If creating an MRE is not applicable or possible, the best next step is to contact SAP support. This will allow the core team to take a deeper look and investigate the performance issue more efficiently. Would that be possible for you?

---

Off-topic but:

One common cause of performance degradation while navigating multiple times in a large application is the increasing number of bindings associated with the main model (e.g. ODataModel) and the application consecutively calling Model#setProperty synchronously within a single call stack. You might want to check your controllers on this.

• Discussion at Model: reason for iterating over all bindings in "checkUpdate"? #2600
• Some recent API setProperty description updates warning about the performance implication: 2bab1bf, cb6c7f7

[Thodd]

Hi @dcwb89,

adding to the answer from my colleague @boghyon:

this is a pretty hard case to judge without seeing the application itself.

Here are a couple of things that come to my mind:

• Are you using HTML in XML? Because that is relying on a preserving mechanism.
• with that many XMLViews, I assume that a lot of them can be covered with Fragments instead.
  Fragments are more lightweight and do not come with preserving or a controller, reducing overhead significantly.

Regarding your statement:

However, this area is never “cleaned up,” so more and more DOM elements accumulate over time.

This sounds indeed strange.
Every time an XMLView is (re-)rendered, any preserved DOM elements will be moved from the preserve-area to the main DOM again. Accumulating 20k DOM Elements is definitely wrong and sounds like a memory leak of some sort.

Some other questions:

• Are we actually talking about the preserve-area? I chatted with our routing expert and there is also the scenario of a NavContainer that retains all navigation views in a hidden invisible area.
• How are you using/loading the XMLViews?
• Do you need a controller for all of them (i.e. is a Fragment sufficient)?
• Can you destroy unused XMLViews manually?

Best regards,

Thorsten

[dcwb89]

Hello,
Thank you all for your answers. We have opened a ticket with SAP Support as recommended. In the mean time, @Thodd, to answer your questions:

Are you using HTML in XML? Because that is relying on a preserving mechanism.

We have a few HTML elements, but these are hardly significant. Its mainly XML views and their content (standard and custom controls)

with that many XMLViews, I assume that a lot of them can be covered with Fragments instead.
Fragments are more lightweight and do not come with preserving or a controller, reducing overhead significantly.

It is a really big app. There is a controller for each of the views, which is also required. Some of the views already consist of fragments, but ultimately, we will probably not be able to get rid of most of the views / controllers.

Are we actually talking about the preserve-area?

The elements definitely accumulate in the preserve area. Deleting it via dev tools superficially solves the problem.

How are you using/loading the XMLViews?

We use the routing definition in manifest.json. Currently still V1, a conversion to V2 is in progress.

Can you destroy unused XMLViews manually?

We did indeed try this, but it led to subsequent errors when navigating to the relevant pages again. According to first estimates, it would take an enormous amount of effort to solve the problem in this way. In addition, this option is the last straw for us for two reasons:

1. we want to stay as close as possible to the framework and best practices in the future. Manually destroying views seems more like a work around to us.
2. the preserve functionality actually offers performance optimizations, which we would of course like to use

Edit: I would like to add that we also use the ui5Linter and have no errors or warnings in the project at all (except for the one that we should migrate manifest.json to V2 - what we are already working on).

[Thodd]

Hi again,

so it's been a while, but we have at least a workaround for this issue.

DOM preservation is something we've addressed targeting the 2.x release of UI5. In that version, only controls that manually implement DOM preservation will leverage this functionality. This means XMLViews won't preserve their content by default anymore, primarily because we've deprecated HTML in XML support.

For the 1.x codebase, however, we've determined that solving this issue in a backwards-compatible way isn't feasible without implementing an opt-out mechanism, which we're not planning to provide at this time.

That said, we do have a similar behavior that's already used internally to suppress XMLView content preservation in certain scenarios.

Our proposed workaround is to patch the sap.ui.core.mvc.View.create() factory function to completely suppress content preservation. Here's how you can implement it:

const origViewCreate = View.create;
View.create = function () {
    return origViewCreate.apply(this, arguments).then(function(oView) {
        if (oView?.oAsyncState) {
            oView.oAsyncState.suppressPreserve = true;
        }
        return oView;
    });
};

This approach essentially brings the 2.x behavior into the 1.x codebase and bypasses any non-control-specific preservation behavior. Controls that implement their own preservation logic won't be affected by this change. This should give you a more reliable solution than manually deleting DOM nodes.

Important: Please keep in mind that this is a workaround and should only be used when you're facing significant issues. Make sure to apply it very early in your application's lifecycle to capture as many internal factory calls as possible – ideally before any async views are created through routing.

I hope this helps resolve the cases you've reported.
Let me know if you run into any issues and I will reopen it.

Best regards,

Thorsten