BSA – WPF Performance Issue part 3

This is the Diagnostics Tools in Visual Studio showing BSA Start-Up. The first big raise of memory usage is probably my Tool View – not sure – but the last one is me moving BSA to the other screen and redrawing the grid in the process. This is the cost – something like 50Mb or so – to recreate the grid because I changed the size. It is a bug here that it never realease the memory, but the real error is is just bad programming or basically me not realizing the cost of using UIElements in arrays.

The irony is that I did the very same mistake some 30 years ago on my very first Windows applications – I nedded a grid and created a grid based on multiple edit controls. The system crashed because I ran out of resources – this version do not crash, but it telling me very clearly that this is not the path forward. UIElement needs to much memory for it to be duplicated the way I do.

I have fixed some other issues that affected performance and they helped, but this I will need to fix by dramatically reduce the number of UIElements I use – I think.

The solution is to create proper controls where both the TreeView (Tool list), Grid and Property Editor is a fixed number of UIElements – not big arrays of them. Beginning with the Property Editor this is easy technically – but a bit of work – I need to create one control that display my tree and then use UIElements to place inline as I want to edit objects. Badically I need to create a proper TreeViewGrid or find one I can use. Taken into account some of the tricks I use to create a functional property editor I expect I will need to create this myself. This is after all a very important part of BSA as details here decides how easee the result will be to use.

Conclusion : Arrays of UIElements use a lot of memory and should be limited.

The upside: I did need a TreeViewGrid anyway!

The downside is that controls also consist of UIElements, so I am not sure I actually have a smart solution here yet…

Categories: HMI

Leave a Reply