|
Every item in a script's Data Section is normally calculated once, up front, and stored in memory -- one value per bar per symbol. References during a test are then simple array reads, and an item that several formulas share is never computed twice. The cost is storage: memory use grows with symbols × bars × items, and a multi-market, multi-system script over a long history can need more memory than the machine has.
The Data on demand option (on the Calculation tab of the Program Options dialog, default off) trades calculation time for memory. When it is enabled, eligible Data items are not stored at all; each reference evaluates the item's formula on the fly, the same way a Library formula would be. A test that needed tens of gigabytes of Data storage can run in almost none -- it just runs more slowly, since values are recomputed at every bar where they are referenced.
The option applies automatically to every eligible item, so the same script runs unchanged on a large-memory and a small-memory machine. There is no need to maintain a separate low-memory copy of a script with its Data formulas moved to Library.
Which Items Stay Stored
Some kinds of Data items only work as stored arrays, and RealTest keeps them stored even when the option is enabled:
•Cross-sectional (breadth) items -- breadth tags such as #Rank, #PctRank, #Count, #Avg and #Sum are computed across all symbols, date by date, and must be stored. (Their input formulas can still be other, on-demand items.)
•Self-referential items -- cumulative formulas that refer to their own prior values, e.g. cum: cum[1] + ...
•DataValueFile items -- their values come from an external file, not a formula.
•#OnePerDate and #OnePerSym items -- these already store only one value per date or per symbol, so there is little to save.
•Items whose formulas contain Random() -- the stored draws must persist so that every reference sees the same value.
•DLL data-calc items, and any items of the same bar size defined before one -- the user DLL is handed pointers to the stored arrays.
Everything else -- moving averages, oscillators, items that reference other Data items, items at a different bar size than the test -- is evaluated on demand.
Results Match Stored Calculation
An on-demand item returns the same value a stored read would have returned, so test results do not change when the option is toggled -- with one qualification. Items built on the EMA family (EMA, RSI, MACD and the other exponential-smoothing functions) are normally stored using a single full-history calculation; on demand they evaluate per bar with the standard lookback bounded by the EMA precision setting, exactly as if the formula had been written inline in a strategy formula. This is the same small difference that the "Extract one-pass items" option governs, and it can occasionally shift a marginal signal.
Performance Notes
•The cost of a reference is proportional to the formula's lookback window (e.g. Avg(C, 200) scans 200 bars each time it is referenced). Items that reference other on-demand items multiply this cost, so keep deeply nested chains in mind if a test is unexpectedly slow.
•Breadth items evaluate their input formulas once per symbol per date during calculation, so scripts that rank complex on-demand factors with #Rank feel the cost most.
•A per-thread cache absorbs repeated references to the same item at the same bar (multiple strategies, entry plus exit formulas), which is the most common pattern.
•With "Log calculation details" (same Calculation tab) enabled, on-demand items are marked *** in the data calculation log, so you can see exactly which items were stored and which were not.
The Out-of-Memory Check
Independently of this option, RealTest computes the projected size of the Data section before allocating it. If it exceeds the amount of memory that can be committed (available RAM plus page file), the run stops immediately with a message reporting how many gigabytes the calculated data items require and how many can be committed, and suggesting that you enable Data on demand if it is not already on. A projection that merely exceeds physical RAM is allowed to run — the operating system uses the page file as needed, which is slow but works. In command line mode, the message goes to the error log and the run exits with the memory error code (4).
|
