Enhanced Performance for Treeviews

List & Label makes extensive use of the windows tree view control. Since version 21, we even support multi selection and Drag & Drop from the Variables/Fields Window. While the tree control works very nicely for a reasonable number of items, things change considerably once we're talking of hundreds of thousands of entries.

This number is quickly reached if you’re working with non trivial database schemas and relations. By default, each and every 1:n relation is “mirrored” as 1:1 relation in the field tree. Thus, if you have a few hundred tables, each with several hundred fields and many relations– you’re doomed. The Windows treeview API is message based and item lookup and iteration is dead slow. And things get worse for multiselect tree views. In order to get the number of selected items, you can’t rely on one of the handy Treeview_… macros (which are internally optimized) but need to loop through all the items, get the selection state of each and count the selected ones. Passing the focus to the tree view can thus result in a delay of more than a second, depending on the schema size of your data.

The same holds for the function wizard (which also has a tree of fields and variables) and several other windows. While working with the Designer is still possible, it’s certainly no fun. Thanks to Thomas Wurl, our Progress Guru, for raising our attention to this issue. He’s currently writing a brand new data provider for Progress which will be covered in another blog post soon.

The solution we implemented for this issue is a separate, internal cache of all the tree items and a separate list for the selected ones. In order to get the state of a particular one we don’t need to SendMessage our way into the tree but can do a quick lookup in our list and iteration is done in the memory based cache. The true challenge was to keep both structures synchronized which took a couple of days for testing, fixing, re-testing etc. but it was absolutely worth the effort. All tree views are blazingly fast now and the design time experience is what you would expect from a best of breed tool. See for yourself – this test setup compares the performance of 21.001 to that of 21.002.

First, we have added 500 tables, each containing 100 fields which makes a whopping 50000 tree view entries. Even the old version doesn’t do too bad, however you can easily see the slight delay when opening and selecting items:

before
Enhanced Performance for Treeviews
after
Enhanced Performance for Treeviews


If we double the number of items to 100000 you can see why this change was really mandatory:

before
Enhanced Performance for Treeviews
after
Enhanced Performance for Treeviews

This feature will be released in version 21 with Service Pack 21.002. If you’re interested in beta testing it feel free to drop me a note and we’ll be sending you updated binaries right away.

Related Posts

Leave a Comment