Connexion UI Memory Footprint Reduction
- Nick Judson
Analytics
For power users, the Connexion UI can consume considerable memory (with associated slow-downs). Work has been done to attempt to reduce the memory footprint, with R3 using about 40% less memory at startup.
Most memory growth during application usage is due to:
Device UI (and backing viewmodels / code-behind): The first time you select a device, the device configuration must be deserialized and the UI constructed. Memory is consumed for building and displaying the device UI, and the backing classes (viewmodels and code-behind). Once a device UI is created, it is cached for the lifetime of the Connexion UI.
Server connections: When the UI connects to a Connexion service, it must download a considerable payload of information. For a large Connexion instance, you can expect about 200MB of memory will be required. If you connect to many different Connexion instances from the same UI, a high memory footprint is expected.
Complex, load-on-demand UIs: Some UIs are very complex and display a lot of data. For example, the channels dashboard displaying 1000+ channels is cpu and memory intensive. Similarly, map tables with many rows and columns are expensive.
Custom code assemblies: The custom code control (which is part of many device UIs) is complex. It must parse and construct a model of your C# project in order to provide many IDE features (such as intellisense, code highlighting, etc.). It also compiles your code into an assembly, often requiring the loading of any referenced assemblies. If your custom code control references large assemblies, this will quickly increase the memory footprint of the UI.
While we will continue to optimize the memory footprint, the best option to minimize UI slow-downs is to restart the application.