At one point I implemented a “document” – basically a tree with all the content in the diagrams and details about each object. You can see an example at left below. As the project grows, so does this tree and the full tree start to take time loading as this is based on a standard WPF component. This was an issue with Forms and MFC (Native C++) as well, so it is not just a WPF issue – loading big trees take time and if you need to maintain info in it the visual tree become a slug slowing down your app – or in this case it slows down BSA as we load and do operations that changes content in the tree. Solution ? In this case I just remove the tree because it was mostly a debug thing – the Dictionary is much lighter and have taken over anyway.
You might remember I wrote about performance issues earlier and this document tree was the cause of them. I accidentally updated the tree while loading making loading slow, and now I realize that any change causing this tree to be updated slow down operations – so for now I simply remove it – If I want it back I will need to implement partial load. This is a visual precentation so rather than loading the full tree I can loan only the visual parts. But, I don’t see the need for this after I implemented the visual Dictionary. And the worst is that I knew this because I have had this issue several times – the proper solution is called “partial load”. I have my custom Tree component used in Dictionary that support this. WPF is capable of handling very big trees very fast, but loading them is slow – so you load only the visual parts as you need them. DataGridView have an excellent callback for this.