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.
Unfortunately, activation email could not send to your email. Please try again.

Grouping Engine

Thread ID:

Created:

Updated:

Platform:

Replies:

26047 Mar 11,2005 03:12 PM Mar 28,2005 03:27 PM Windows Forms 3
loading
Tags: Grouping
Faraz Haque
Asked On March 11, 2005 03:12 PM

Is there a way to turn off the grouping engine for the grouping grid so that I get the same performance from the gridgrouping control as from the datagrid control. I would like to maintain a consistant looknfeel using the gridgroupingcontrol, but the performance is pretty poor, and I have to avoid using it in cases i dont need the grouping feature.

Administrator [Syncfusion]
Replied On March 12, 2005 11:12 AM

Hi Faraz, this is currently not possible. But it sounds like a good idea to provide a "pass-through" mode where you have a 1-1 mapping between display elements and items in the underlying datasource similar to the way things are handled in a GridDataBoundGrid. We''ll do some research to find out how difficult that is to implement such a feature. Stefan >Is there a way to turn off the grouping engine for the grouping grid so that I get the same performance from the gridgrouping control as from the datagrid control. I would like to maintain a consistant looknfeel using the gridgroupingcontrol, but the performance is pretty poor, and I have to avoid using it in cases i dont need the grouping feature.

Administrator [Syncfusion]
Replied On March 14, 2005 12:51 AM

Let me second that. If you could turn grouping off when unnecessary (while still allowing sorting), it would make my program''s performance increase dramatically. I only need grouping about 10% of the time, but use a GridGroupingControl all the time...

Administrator [Syncfusion]
Replied On March 28, 2005 03:27 PM

I have some really good news with regards to being able to bypass/optimize the grouping engine behavior. A release version for this is still a few weeks away but I wanted to give an update here. We''ll have private builds for testing this soon. Based on the schema that you specify the engine will determine if certain optimizations can be applied. So, if you do have a flat table and don''t sort the records VirtualMode will be applied and the records don''t have to be touched at all (only when drawing). If you sort records then TreeTables will be built so that the grid can sort the records but the logic for filtering and grouping is turned off (see WithoutCounter optimization below). You''ll also have the option for pass-through sorting. Then the table is sorted using the DataView.Sort routing and records will be accessed with VirtualMode. If you group records or if you have nested tables then full grouping logic will be needed. In addition to being able to specify VirtualMode or WithoutCounter mode, you can also specify which counters you need. Most of the times you only want to count Visible elements and filtered records and you can leave out custom counters, hidden element counter and others. That can save you a few bytes per record (40-80 bytes ...). The engine will also determine whether records actually need to be broken into pieces or if a record can be returned as leave elements (RecordsAsDisplayElements option). This again saves a few bytes per record. The following is a list of optimizations. By default they will be turned off, but you can tell the engine which optimizations can be applied when the underlying criteria for the optimization are met: /// /// Specifies various optimization the engine can use when applicable. These optimizations can be used /// in combination with EngineCounter setting. /// /// /// Allowing certain optimizations does not mean that the optimzation is necessarily used. Optimizations /// will only be used when applicable. Take for example the optimization. If you /// allow this optimization the engine will check schema settings when loading the table. If there are /// no SortedColumns, RecordFilters, GroupedColumns and no nested relations for a table, then virtual mode /// can be used and no records need to be loaded into memory. If the user later sorts by one column, the /// virtual mode can not be used any more. Records will need to be iterated through and sorted and tree /// structures will be built that allow quick access to records and IndexOf operations. When initializing the /// table the engine will check if criteria for DisableCounters optimization are met. /// public enum EngineOptimizations { /// /// All optimizations are disabled. /// None = 0, /// /// When the engine detects that a table does not have RecordFilters, GroupedColumns /// or nested relations, counter logic will be disabled for the RecordsDetails collection /// since all counters are in sync with actual records (e.g. all records in datasource /// are shown in TopLevelGroup). With this optimization the engine does still have full /// support for sorting. /// DisableCounters = 1, /// /// When all criteria are met for the optimization and in addition to that /// no SortedColumns are set, the RecordsDetails collection does not have to be initialized at all. /// Instead, it can create records elements on demand and discard them using regular garbage /// collection when no references to a Record exist any more (e.g. once you scroll them out of view). /// This approach reduces memory footprint to absolute minumum. You should be able to load and /// display millions of records in a table. /// The PrimaryKey collection is still supported, but it will be initialized only on demand if you /// do access the Table.PrimaryKeyRecords collection. In such case all records will be enumerated. /// VirtualMode = 2, /// /// When all criteria are met for the optimization and SortedColumns are set, /// the engine will normally have to loop through records and sort them. When you specify /// the engine will check if the datasource is an IBindingList and if IBindingList.SupportsSort returns true. /// In such case the datasource will be sorted using its IBindingList.Sort routine and the engine will /// access records using VirtualMode. Using the IBindingList is usually a bit faster than the engines own /// sorting routines, but the disadvantage is that you will loose CurrentRecord and SelectedRecords information. /// Also, inserting and removing records will be slower (especially if the underlying datasource is a DataView). /// PassThroughSort will be ignored if criteria are met for the optimization are not /// met. If you want to force a Pass-through sort mechanism in such case check out the GroupingPerf example. It /// implements the IGroupingList interface. Normally, it is recommended to use the engines own Sort mechanism /// and only rely on PassThroughSort for Virtual mode scenarios. /// PassThroughSort = 4, /// /// When the engine detects that records do not have nested child tables, no record preview rows are being used /// and each record only has one row (no ColumnSets are used), records do not have to be split into RecordParts. /// Instead when qerying the DisplayElements collection for a specific row, the engine can simply /// return a Record element instead of a RecordRow element. The same applies to CaptionSection, ColumnHeaderSection /// and FilterBarSection. Instead of returning a CaptionRow, ColumnHeaderRow or FilterBarRow element /// the DisplayElements collection retuens the section element. /// /// If you use this optimizaton you need to carefull in your own code and be aware that when you query /// the DisplayElements collection instead of a RecordRow element a Record elemnt can be returned. Same issue /// also with ColumnHeader, FilterBase and Caption. /// RecordsAsDisplayElements = 8, /// /// Enables the , and /// optimizations. /// [Browsable(false)] All = DisableCounters|VirtualMode|PassThroughSort|RecordsAsDisplayElements } The next enum allows you to specify the CounterLogic: /// /// Specifies the counter logic to be used within the engine. If you have large datasources /// and need support for groups and filtered records you can reduce the memory footprint /// by selectively disabling counters you do not need in your application. See WithoutCounter /// for completely disabling counter logic for the RecordsDetails collection and VirtualMode /// for using the engine in a virtual mode. /// public enum EngineCounters { /// /// Counts visible elements and filtered records. Smallest memory footprint. /// /// /// /// Table.DisplayElements.GetItemAtYAmount and Table.DisplayElements.GetYAmountPositionOf /// are not supported. /// The Table.Elements collection will only return visible elements (same resultset as Table.DisplayElements) /// The Table.Records collection will return only filtered records (same resultset as Table.FilteredRecords) /// The Group.Records collection will return only filtered records (same resultset as Group.FilteredRecords) /// Table.DisplayElements.GetVisibleCustomCountPositionOf and Table.DisplayElements.GetItemAtVisibleCustomCount /// are not supported. /// Table.DisplayElements.GetCustomCountPositionOf and Table.DisplayElements.GetItemAtCustomCount /// are not supported. /// /// FilteredRecords, /// /// Counts visible elements, filtered records and YAmount. Medium memory footprint. /// /// /// /// Table.DisplayElements.GetItemAtYAmount and Table.DisplayElements.YAmountIndexOf /// are supported. /// The Table.Elements collection will only return visible elements (same resultset as Table.DisplayElements) /// The Table.Records collection will return only filtered records (same resultset as Table.FilteredRecords) /// The Group.Records collection will return only filtered records (same resultset as Group.FilteredRecords) /// Table.DisplayElements.GetVisibleCustomCountPositionOf and Table.DisplayElements.GetItemAtVisibleCustomCount /// are not supported. /// Table.DisplayElements.GetCustomCountPositionOf and Table.DisplayElements.GetItemAtCustomCount /// are not supported. /// /// YAmount, /// /// Default. All counters are supported: visible elements, filtered records, YAmount, hidden elements, hidden records, CustomCount and VisibleCustomCount. Highest memory footprint. /// /// /// /// Table.DisplayElements.GetItemAtYAmount and Table.DisplayElements.YAmountIndexOf /// are supported. /// The Table.Elements collection will return all elements (including hidden elements that are not visible) /// The Table.Records collection will return all records (including records that do not meet filter criteria) /// The Group.Records collection will return all records (including records that do not meet filter criteria) /// Table.DisplayElements.GetVisibleCustomCountPositionOf and Table.DisplayElements.GetItemAtVisibleCustomCount /// are supported. /// Table.DisplayElements.GetCustomCountPositionOf and Table.DisplayElements.GetItemAtCustomCount /// are supported. /// /// All } Stefan

CONFIRMATION

This post will be permanently deleted. Are you sure you want to continue?

Sorry, An error occured while processing your request. Please try again later.

You are using an outdated version of Internet Explorer that may not display all features of this and other websites. Upgrade to Internet Explorer 8 or newer for a better experience.

;