We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy. Image for the cookie policy date

Performance issue while iterating through FilteredRecords (

I have a performance problem with the grouping table while testing the sorting. I add 10,000 objects in an ArrayList then I call arrayList.Sort with my Comparer. The Sort only takes about 60ms. Iterating through this list takes virtually no time. When using grouping table with the same sort criteria and iterating through the FilteredRecords - it takes about 1600ms for the same operation.

4 Replies

AD Administrator Syncfusion Team July 21, 2004 05:18 PM UTC

Mike, Can you post your sample? Then I can take a look how it can be optimized. Howver, iterating through the FilteredRecords collection will always be slower than iterating directly through an ArrayList. The grouping engine holds all data in binary trees. Therefore when iterating through the list you will actually be traversing a tree. The advantage of using binary trees is when you insert, remove or change data and when you want to do IndexOf(record) operations. These will be faster. Stefan

MI Mike July 21, 2004 06:26 PM UTC

Stefan, Thanks for your answer. I''m simply using this code below: engine.SetSourceList( anArrayList ); table = engine.Table table.TableDescriptor.SortedColumns.Clear(); table.TableDescriptor.SortedColumns.Add( "aProperty", ListSortDirection.Aschending ); for( int i < table.FilteredRecords.Count; i++ ) { Record aRecord = table.FilteredRecords[ i ]; aList2.Add( aRecord.GetData() ); } ------------------------------------- If I use the ArrayList.BinarySearch and insert at the right index why should that be slower than the grouping inserts? Thanks Mike

AD Administrator Syncfusion Team July 22, 2004 03:22 PM UTC

I attached a small sample I created so you can see which operations take how much time. One thing you should check out is the RecordsAsDisplayElements option. Then the engine can skip creating child elements for records if you don''t need them. When you assign a datasource to the engine the engine will keep an array (which is a binary tree actually) of the orginal source list entries and and an array (binary tree) of the records in the sort order as displayed by the table. The table that is displayed in the engine has a totally different sort order than the items in the underlying source list. If you now make changes to the underlying source list, e.g. Insert an item in there for the ArrayList itself is not big a deal. What will happen if you insert at position n, all items from position n+1 will be just shifted one item to the right. Only if the array needs to grow, it will create a new array of a bigger size and copy values over. This is a worst-case O(n) operation. With the grouping engine things get a bit more complicate. Each element in the table that is displayed now needs to be updated with the new record indexes. So, what it would neeed to do is loop through all its records, check for the underlying source index and update its reference index. So you would have again a O(n) operation. Additionaly other collections (DisplayElements, FilteredRecords, CustomCounters, Summaries) all also would have to be update by just linear looping through the lists. This gets soon quite complicate ... That''s where balanced binary trees come into play. They allow to quickly react the engine to updates, inserts, deletions etc from the underlying source list with O(log2(n)) operations. Of course the performance of your underlying source list will not be changed. Only the overhead is minimized. Another important thing is being able to look up the position of a record. Suppose you change a record in the underlying list. You can quickly get the source index from the ListChanged event which record was changed. However, based on that index you quickly need to be able to determine the position in the sorted record list table. Using IndexOf() only takes O(log2(n)) with binary trees. Also summaries. When you update a value in the source list you don''t iterate through all values, instead any custom summary can be recalculated in O(log2(n)) time. The disadvantage of binary trees are they take longer to initialize and also when you access an element it also takes O(log2(n)) instead of direct access / O(1) time. The engine tries to optimize these disadvantages but it will never be as fast as direct access. Hope this explanation clarifies things a bit. Stefan

AD Administrator Syncfusion Team July 22, 2004 03:23 PM UTC

Attached find the sample. IterateFilteredRecords_5742.zip Stefan

Live Chat Icon For mobile
Up arrow icon