Defines the constants that specifies the various optimization the engine can use when applicable. These optimizations can be used in combination with EngineCounter setting.
[Flags] public enum EngineOptimizations
Allowing certain optimizations does not mean that the optimization is necessarily used. Optimizations will only be used when applicable. Take for example the VirtualMode 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.
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.
All optimizations are disabled.
When all criteria are met for the DisableCounters optimization and SortedColumns are set, the engine will normally have to loop through records and sort them. When you specify PassThroughSort 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 DisableCounters 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.
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 querying 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 returns the section element.
If you use this optimization you need to careful in your own code and be aware that when you query the DisplayElements collection instead of a RecordRow element a Record element can be returned. Same issue also with ColumnHeader, FilterBase and Caption.
When all criteria are met for the DisableCounters 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 minimum. 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.