Burst Load Modes

Burst Load Modes are alternative ways of retrieving objects in the SQL brokers of InstantObjects. You select them case by case with the property RequestedLoadMode of a TInstantSelector or a TInstantQuery, setting one of these values of TInstantLoadMode:

Value	Mode
lmKeysFirst	The standard, historical load mode (the default)
lmPartialBurst	Partial Burst
lmFullBurst	Full Burst

What does it do

When InstantObjects retrieves a set of objects through a SQL broker, in the standard mode the order of operations is:

1. execute a select statement (the primary query) that retrieves the primary keys of all the objects selected by the IQL command;
2. fetch all the records (up to MaxCount);
3. for each record accessed, materialize the object. This executes one or more select statements to get all the object data (the main object query), the containers and the references (the accessory queries). External storage implies more queries. The main query joins all the tables of the class and of its ancestors.

Full Burst changes these steps:

1. the primary query retrieves all the object data, not just the primary keys;
2. all the objects are materialized (up to MaxCount) from the data set obtained. This executes all the accessory and external queries that in the standard case are executed at step 3, but not the main query, which is not needed any more.

Partial Burst works this way:

1. like Full Burst, step 1;
2. like the standard mode, step 2;
3. like the standard mode, step 3, but using the data retrieved by the primary query and kept around: the objects are materialized on demand.

So Full Burst is much quicker when retrieving a whole data set, while the standard mode is best at getting the first records. Partial Burst gives the best of both: it is almost as quick as Full Burst when fetching an entire data set, and slightly quicker than the standard mode at getting the first records.

When to use burst load

• Full Burst is well suited when objects are selected (typically with an IQL command with a WHERE clause) to be processed: if the entire data set is going to be fetched and all the records visited anyway, it is much quicker.
• The standard mode is of the "lazy load" kind: it suits a list of objects displayed for browsing, typically in a DBGrid, when not all the objects are needed and just one or a few are selected. Displaying the first records is much quicker in standard mode.
• Partial Burst covers both cases, so it is the preferred mode. The only glitch is that it keeps the database connection open for longer than Full Burst. If that is a concern, use Full Burst instead.

Performance notes

These are quick benchmarks done in 2010 with one of the example queries of PrimerExternal (select * from TCompany) and a data set with a couple of thousand records. The database was a local Firebird server and the compiler Delphi XE. All the caches were flushed at each iteration; three iterations for each test (average value, in seconds). KF is the standard mode (keys first), PB Partial Burst, FB Full Burst.

Test	KF	PB	FB
No fetch, just open a selector and fetch some 20 objects for a DBGrid	0.9	0.8	36.1
Fetch all the records and materialize all the objects (while not Eof do Next)	65.5	45.4	45.4
Same as above, with the statement cache enabled	38.6	28.9	29.5

Using Full Burst when it is not appropriate can hurt performance, which is why it is disabled by default and enabled only on request. Partial Burst appears suitable for most cases.

Caveats

• Burst Load modes are not supported for IQL commands that use the ANY keyword. In that case the system silently falls back to a supported mode: inspect the property ActualLoadMode to see the mode really used.
• External Part attributes and all Reference attributes still need separate queries.
• A mixture of the standard and the burst modes (a standard mode in which some chosen attributes are fetched together with the primary keys) would allow to display a list of objects in a grid without materializing them, as quickly as with direct SQL queries. It has not been implemented.

See also the statement cache of the brokers, and TInstantLoadMode in the InstantTypes reference.

---

Originally written by Nando Dessena, 2010.