In 2026.4, every time a new model is loaded using loadSubtreeFromModel(), the browser memory usage appears to increase significantly (roughly doubles) and is not released afterward.
The same workflow in 2023 SP1 does not exhibit this behavior, and memory remains relatively stable across multiple load operations.
Questions
Were there any changes to the internal implementation of loadSubtreeFromModel() between 2023 SP1 and 2026.4 that could affect memory usage?
Is there any additional cleanup/unload API that should now be called after removing or replacing a subtree?
Are there known memory leaks or regressions related to linked model loading in 2026.4?
What is the recommended way to completely unload a subtree loaded through loadSubtreeFromModel() and reclaim memory?
Additional Information
Source version: 2023 SP1
Target version: 2026.4
Memory increase is observed after repeatedly loading new models.
The issue appears specifically related to subtree/model loading rather than general viewer operations.
Any guidance on debugging or profiling this would be appreciated.
I’m not able to reproduce the issue when loading a model and subsequently deleting it. The memory consumption remains stable throughout in both v2023 SP1 and v2026.4.0.
Here is the test that I did using the stock arboleda model that comes with the Visualize Web package:
const delay = ms => new Promise(resolve => setTimeout(resolve, ms));
await hwv.model.clear();
for (let i = 0; i < 50; i++) {
let modelLoad = await hwv.model.loadSubtreeFromModel(hwv.model.getAbsoluteRootNode(), "arboleda");
await delay(1000);
await hwv.model.deleteNode(modelLoad[0]);
console.log("Load #: " + i);
}
It may be necessary for us to get the model(s) that you are using in order to do a deeper analysis. In that regard, please create a Visualize Web support ticket via our support portal (login required).
Our model is split into multiple smaller files (typically less than 10 MB each) that are loaded on demand using loadSubtreeFromModel(). The loaded subtrees remain in the scene and are not deleted.
With HOOPS Communicator 2023 SP1, loading multiple files resulted in relatively stable memory usage. However, after upgrading to HOOPS Communicator 2026.4, we are seeing significantly higher memory consumption for the same workflow.
In addition, after the files are loaded, normal viewer interactions such as orbit, pan, and zoom cause GPU utilization to increase to around 60–80%, which was not observed with the same models in 2023 SP1.
Could you let us know if there were any changes in model loading, rendering, geometry processing, caching, or GPU resource management between 2023 SP1 and 2026.4 that could explain the increase in memory usage and GPU utilization?
There have been numerous bug fixes, enhancements and new features introduced between Communicator 2023 SP1 and Visualize Web 2026.4.0. However, there are none that would explain the inordinately high deltas in memory utilization as you had described.
It would be best that we get the models in question so that we may diagnose the issue better. To that end, I’ve initiated that the process of creating a support account for you. You should be receiving a separate email soon.
Thanks. One question: could the performance issue be related to using models that were exported with Communicator 2023 SP1 and then viewed in the latest 2026.4 version?
I noticed a difference in behavior between the two versions. Specifically, when calling:
let sheetIds = viewer2d.sheetManager.getSheetIds();
the returned sheet IDs are unique in 2023 SP1, but in 2026.4 I am seeing duplicate entries. Could this difference be contributing to the performance or memory issues we are observing?
This sounds more like either a bug fix or even a feature in more recent versions of Visualize Web/Communicator.
Let’s say you loaded the same drawing twice using loadSubtreeFromModel(). I would expect a unique IDs for the same drawing. Each time to load the same drawing there is an offset to avoid node ID clashing. I don’t think this is the issue with the high memory consumption.
Here is a simple test to try:
Expose the viewer alias as a global variable so that you can call WebViewer functions in the dev console.
Then call:
await hwv.model.clear();
let modelLoad = await hwv.model.loadSubtreeFromModel(hwv.model.getAbsoluteRootNode(), "name_of_your_models");
The above snippet will clear the model and load the model once. Then call loadSubtreeFromModel() multiple times as needed to aggregate your model. Is the memory increasing substantially in v2026.4.0?
If we comment out this line in 2026.04, the performance issue appears to be resolved or significantly reduced. However, in Communicator 2023 SP1, the application performs correctly even with StreamingMode.All enabled.
Has there been any change in the behavior, implementation, or performance characteristics of StreamingMode.All between 2023 SP1 and 2026.04 that could explain this difference? Are there any known issues or recommendations regarding its usage in newer releases?
This clearly states:
2023 SP1 works fine with StreamingMode.All.
2026.04 shows performance issues with it enabled.
Commenting it out improves performance in 2026.04.
We’ve made performance improvements with the different streaming modes, namely Communicator.StreamingMode.Interactive. It would really be best if you created a support ticket in our support portal. If there is a bug, we will need the source CAD files and reproduction steps anyway.