Professional UI Solutions
Site Map   /  Register


Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS Tech Support » Tree grid sorting performance Collapse All
Subject Author Date
Rado Manzela Mar 11, 2010 - 7:24 AM

I’m using tree grid with sortable columns, but it it seems to be too slow. My tree has abot 3 levels with approx. 1500 items total and sorting takes 5 or more seconds on Athlon XP 3400+ with 100% CPU load.  Is it possible to optimize it? Especially when reversing sorting order, items are already sorted, you could just reverse order instead of making full order again.

I’ve tried to find another optimizations, in ItemSortChildrenDeep() you call ItemSortChildren() for each parent node which calls OnSwUpdateScrollBars(); each time, maybe also other stuff redundantly. Is it really necessary? I’ve made my own version of deep sort which calls it only once at the end, wich is bit faster, but I’m not sure whether it is 100% safe.

Technical Support Mar 20, 2010 - 1:06 PM

The following small improvement can make sorting 20% faster:bool CExtTreeGridDataProvider::_Tree_SortSwapSeries(
LONG nRowNo1,
LONG nRowNo2,
LONG & nSwapCounter,
CExtTreeGridDataProvider::ITreeDataProviderEvents * pDPE,
CExtTreeGridCellNode * pNodeParent
__EXT_DEBUG_GRID_ASSERT( nRowNo1 != nRowNo2 );
__EXT_DEBUG_GRID_ASSERT( nSwapCounter >= 0L );
CExtTreeGridCellNode * pNode1 = pNodeParent->TreeNodeGetChildAt( ULONG(nRowNo1) );
CExtTreeGridCellNode * pNode2 = pNodeParent->TreeNodeGetChildAt( ULONG(nRowNo2) );
if( pDPE != NULL )
pDPE->OnTreeDataProviderSwapSeries( *pNode1, *pNode2, nSwapCounter );
nSwapCounter ++;
CExtTreeGridCellNode * pNodeCopyMove = ( nRowNo2 > nRowNo1 ) ? pNode2 : pNode1;
ULONG nIdxInsertBefore = ULONG( ( nRowNo2 > nRowNo1 ) ? nRowNo1 : nRowNo2 );
//CExtTreeGridCellNode * pNode3 = _Tree_NodeCopyMove( pNodeCopyMove, pNodeParent, nIdxInsertBefore, true, false );
// if( pNode3 == NULL )
// return false;
__EXT_DEBUG_GRID_VERIFY( _Tree_NodeMoveImpl( pNodeCopyMove, pNodeParent, nIdxInsertBefore, TVE_TOGGLE ) );
return true;
We just don’t need to check whether the specified tree nodes can really be swapped. I.e. whether one is not child of other one.
But this generally does not solve the speed problem. The real source of this problem is that the CExtTreeGridWnd tree grid is the adopted version of the CExtGridWnd plain grid control. This fortunately makes all the grid cells and most other features of the plain grid control available in the tree grid control. But we had to track the linear list of expanded items constantly. This is extremely required by the CExtGridWnd class code and by all of its subsystems, especially by the data provider component. The current version of the tree grid sorting algorithm is some kind of universal algorithm which can work with any sub-branches of rows inside the tree grid. This algorithm cannot be seriously faster. But we can re-code the tree grid sorting for the particular case when the entire tree grid is sorted. It’s possible to make such particular sorting task seriously faster.

Rado Manzela Mar 22, 2010 - 8:22 AM

Thank you, but it seems the speedup is not measurable in my case (definitely not 20% on my computer). I hope you’ll make faster at least reversing of the sort order (when tree is ordered by some column and user just clicks the column again to get reversed order) in next release.


Technical Support Mar 17, 2010 - 2:32 AM

It seems you forgot to include the CellStatNumber.h file into the ZIP archive.

Rado Manzela Mar 17, 2010 - 3:37 AM

I’m sorry, please just delete cellstatnumber.cpp , it is not used in the project, it was just numeric cell with different color.

Technical Support Mar 15, 2010 - 5:20 AM

The tree grid swaps tree rows with/without children during sorting each tree level. The tree grid does not swap rows that do not need to be swapped during sorting. The speed of sorting depends on the number of rows, the number of columns in sorting rules and the type of grid cells. The speed is much faster in release than in debug. To make debug working with the speed that is close to release you should invert the commented state of the following lines of code at the beginning of the ../Prof-UIS/Include/ExtGridWnd.h file:

// #define __EXT_DEBUG_GRID_ASSERT_VALID( __PTR__ )                                                        ;
//          #define __EXT_DEBUG_GRID_ASSERT_KINDOF( __CTYPE__, __PTR__ )                     ;
//          #define __EXT_DEBUG_GRID_ASSERT( __SOME_EXPR__ )                                                     ;
//          #define __EXT_DEBUG_GRID_VERIFY( __SOME_EXPR__ )                                                      __SOME_EXPR__ ;

            #define __EXT_DEBUG_GRID_ASSERT_VALID( __PTR__ )                                                        ASSERT_VALID( __PTR__ ) ;
            #define __EXT_DEBUG_GRID_ASSERT_KINDOF( __CTYPE__, __PTR__ )                     ASSERT_KINDOF( __CTYPE__, __PTR__ ) ;
            #define __EXT_DEBUG_GRID_ASSERT( __SOME_EXPR__ )                                                     ASSERT( __SOME_EXPR__ ) ;
            #define __EXT_DEBUG_GRID_VERIFY( __SOME_EXPR__ )                                                      VERIFY( __SOME_EXPR__ ) ;

Then you should rebuild the required Prof-UIS configurations and your project(s). Please provide us with additional information about the cell data types in your tree grid control.

Rado Manzela Mar 16, 2010 - 9:17 AM

I was talking about release version. I’ve created some sample:;/p>

Compiled in VS 2005, release, (re)ordering  takes 4,5 sec on my computer. (time is displayed in dialog after ordering).