Timing HaasScripts

When optimizing HaasScript performance, you need to measure how long different parts of your script take to execute. HaasScript provides timer commands specifically for this purpose: profiling execution time during script updates to identify bottlenecks and slow code sections.

How Script Execution Works

HaasScript scripts run on every update cycle. Each update runs from top to bottom, line by line, then completes. Any variables you define in one update are not visible in the next—each update starts fresh. This means any timing measurements are per-update only.

Timer Commands

HaasScript provides three commands for measuring execution time:

• StartTimer([key]) - Starts a timer with an optional key for multiple timers
• GetTimer([key]) - Gets the elapsed time for a timer in milliseconds
• StopTimer([key]) - Stops a timer and returns elapsed time in milliseconds

All times are measured in milliseconds.

Basic Timer Usage

The simplest approach uses a single timer without a key:

-- Start the timer
StartTimer()

-- Your code to measure
local rsi = RSI(ClosePrices(), 14)
local macd = MACD(ClosePrices(), 12, 26, 9)

-- Get elapsed time (timer continues running)
local elapsedTime = GetTimer()  -- Returns milliseconds

-- Stop timer and get final elapsed time
local totalTime = StopTimer()

Using Multiple Timers

When you need to measure multiple code sections, use keys to differentiate timers:

-- Measure different parts of your script
StartTimer('indicators')
local rsi = RSI(ClosePrices(), 14)
local bb = BBANDS(ClosePrices(), 20, 2.0, 2.0)
local indicatorTime = StopTimer('indicators')

StartTimer('trading-logic')
if rsi < 30 then
    DoLong()
end
local logicTime = StopTimer('trading-logic')

-- Log the results
Log('Indicators: ' .. indicatorTime .. 'ms')
Log('Logic: ' .. logicTime .. 'ms')

Interpreting Timer Results

When reviewing your timer output, consider these guidelines:

• Market data retrieval with ClosePrices, HighPrices, etc.
• Indicator calculations vary with complexity. SMA is fast; complex custom indicators may be slower
• Trading logic should be negligible
• Total per-update time should stay under reasonable limits for your use case

If one section consistently shows high times, focus optimization efforts there.

Common Bottlenecks

Based on timing results, look for these common performance issues:

Large lookback periods:

-- Potentially slow with very large lookback
local sma500 = SMA(ClosePrices(), 500)

Multiple redundant calculations:

-- Better: Calculate once, store in variable
local closePrices = ClosePrices()
local rsi = RSI(closePrices, 14)

-- Avoid: Multiple calls to same data
if RSI(ClosePrices(), 14) < 30 and RSI(ClosePrices(), 14) < 50 then
    -- ...
end

Timer Limitations

• Per-update only: Timers reset each script update. They do not persist across updates
• No historical data: You cannot access timing data from previous updates
• Update cycle timing: Timers measure execution within the update cycle only
• Overhead: The timer commands themselves have minimal overhead

Best Practices

1. Profile during development: Add timers when developing complex scripts, remove them in production
2. Use descriptive keys: meaningful timer keys make it easier to identify what's being measured
3. Measure consistently: Profile under similar market conditions for fair comparisons
4. Focus on relative differences: Absolute times matter less than identifying the slowest parts
5. Remove after optimization: Clean up timer code once you've identified and addressed bottlenecks