data virtualization (TreeListBox)

Grids for WPF Forum

Posted 3 years ago by Andrew Levine
Version: 22.1.0
Avatar

I have an array of items that implement an interface called IMatchDisplayItem. Many of the items in the array are a reference to the same object in memory. When I pass the array as Children, the total amount of memory used by my program (including the UI) is about 300 MB for 2 million items. But when I pass an array of wrapper objects for these same items, the total memory doubles to 600 MB. I'm trying to use data virtualization but it doesn't seem to have any effect. Do you have any samples of data virtualization in the TreeListBox? No matter what I do, it seems to generate "Actipro.Internal.gX" objects for all items in the array, and a dictionary of <Object, gX> which are responsible for most of the memory overhead.

Comments (3)

Posted 3 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Andrew,

I believe the gX objects (obfuscated name) are our internal TreeNode class instances that track the relationship of items within the tree.  There is a dictionary that maps your "item" objects to our TreeNode class.  TreeNode objects are created whenever an item is examined, even if data virtualization is active.

While we don't currently have a sample for data virtualization, it will still create the same number of TreeNode objects behind the scenes.  It's just that it won't load the actual items until they are needed.  But it still will be creating TreeNodes objects with ITreeItemVirtualPlaceholder objects.

If you have an enormous number of items like that, perhaps changing the children query mode would be better.  As explained in this topic, by default when a node is going to be made visible, all of its child nodes are queried to see if there are any.  This allows us to hide the expander box if there are no children.  The downside of that is that there is one level deeper of children queries happening, which could be a performance bottleneck in enormous trees.  You can change the TreeListBoxItemAdapter.GetChildrenQueryMode method result (or simply set the adapter's ChildrenQueryModeDefault) to TreeItemChildrenQueryMode.OnExpansion instead of OnDisplay.  That will always show an expander box until a node is expanded.  At that point, it will scan the children for display and will hide the expander box if there are no children.  This prevents that extra level of children scanning until necessary for display, and thus creates fewer TreeNodes behind the scenes.


Actipro Software Support

Posted 3 years ago by Andrew Levine
Avatar

It seems the super low memory state only happens when object1 is object2 in the source children list... however that messes up the children query so that only the first treenode based on object1 shows its children, and later ones don't expand. Is there any setting that will fix this? or can I hack into the tree node generation somehow and tweak it for my needs? It would be ideal because I expect 300 mb memory to be multiplied by the number of open documents in my program.

Also I'm having some trouble calculating the correct path for a given item when more than one are the same object... will some kind of TreeNavigator method help to figure out which index in the children array is being clicked on? Thanks again!

Answer - Posted 3 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Andrew,

The items in the TreeListBox will need to be unique so that the Dictionary<object, TreeNode> mapping of item-to-TreeNode can work.  It should be working off of your items' Equals() methods to determine equality.  But if you have multiple items that are the same (in terms of Equals()), then functionality of the TreeListBox could be compromised, including our ability to map items to nodes, paths, selection, etc.  So unfortunately wrappers would be needed if your true items are being reused.


Actipro Software Support

The latest build of this product (v24.1.3) was released 28 days ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.