1.56 s
1,000 EMA variants
Elapsed time for a full cold sweep of 1000 related EMA strategy variants in the Node/service benchmark boundary.
Current benchmark evidence
2Signals Engine results and tests.
This page keeps the focus on what is actually useful: measured boundaries, correctness gates and the commands that reproduce the evidence. It is not a daily-generated whitepaper system.
241-258 ms
Fully rendered UI
Time until the production-like Builder harness has chart, signals, trades and metrics ready for inspection.
0
Mismatched fields
Trade-level comparison fields that differed between 2Signals current-engine export and the frozen Freqtrade reference.
Presentation prep
Use one briefing, one benchmark anchor, one story.
The goal is not to memorize every report. For a presentation, start from the practical brief and keep the source reports ready only for technical questions.
Open presentation briefStart with the brief
Read `docs/whitepaper/README.md` first. It contains the talk track, 8-slide flow, key numbers, Q&A and what not to claim.
Use one benchmark anchor
Use `docs/benchmarks/results/2signals-vs-freqtrade-main-v1.md` as the main technical evidence for correctness plus timing.
Ignore old entry points
Treat v0.1, v0.2 and v0.3 as historical/supporting drafts. Do not start your prep there.
Results
Start with the comparison, then use supporting evidence blocks.
The main report answers the 2Signals/Freqtrade question. The supporting blocks explain scaling, UI latency, Freqtrade boundaries and the complex futures correctness case.
Median
Median elapsed time across measured samples. It is used instead of a single run because local timings have noise.
Why: Gives a stable central value for comparison without overreacting to one slow or fast sample.
Cold run
A run where benchmark-level caches are cleared or treated as empty for the measured boundary.
Why: Shows the cost when reusable work is not already available.
Warm run
A repeated run over the same boundary after reusable work has already been computed.
Why: Shows whether cache reuse actually helps without changing correctness.
Presentation-ready
The point where computed results are available to the presentation layer.
Why: Separates engine/service work from the cost of drawing a usable analytical UI.
Fully rendered
The point where the benchmarked UI has chart, indicator series, markers, trades and metrics rendered.
Why: Closer to what a user experiences than engine-only timing.
Mismatched fields
Count of compared correctness fields that differ between the two controlled outputs.
Why: Timing is not useful if the engines disagree semantically.
Controlled local benchmark boundaries
2Signals vs Freqtrade
The current front-door report for the question that matters most: do 2Signals and Freqtrade match, and what are the measured timing boundaries?
docs/benchmarks/results/2signals-vs-freqtrade-main-v1.md
| Statistic | Value | What it measures | Why it matters |
|---|---|---|---|
| EMA side-by-side correctness | passed, 0 mismatches | Correctness gate for the simple EMA side-by-side benchmark over the same frozen BTC/USDT 5m dataset. | This proves the timing rows are tied to matching outputs, not just separate benchmark runs. |
| EMA timing snapshot | 2Signals 20.25 ms; FT strategy-list 5.51 s; FT CLI 35.52 s | Median workflow timings for 10 shared EMA variants in the currently measured boundaries. | This is the cleanest current correctness-plus-timing comparison, with explicit workflow boundaries. |
| Complex futures correctness | passed, 123 trades, 0 mismatched fields | Fresh current-engine 2Signals output compared with fresh Freqtrade output on the complex futures fixture. | This is the strongest current non-trivial correctness signal. |
| Complex timing snapshot | 2Signals 2.45-2.47 s; FT Backtesting.start 20.32 s | Controlled local timing boundaries for the complex futures run. | Shows the current timing evidence for a larger strategy while keeping process and artifact boundaries visible. |
2Signals Node/service boundary
Variant scaling
Controlled EMA fast 50-59+ scale runs over a frozen BTC/USDT 5m dataset. This measures the strategy computation path, not UI rendering or external data fetching.
docs/benchmarks/results/controlled-ema-2signals-variant-scale-btcusdt-5m-v2.md
| Statistic | Value | What it measures | Why it matters |
|---|---|---|---|
| 10 variants cold median | 16.26 ms | Elapsed time to compute the full 10-variant EMA sweep with caches cold for this boundary. | Acts as the smallest scale baseline and catches benchmark overhead. |
| 100 variants cold median | 151.18 ms | Elapsed time to compute the full 100-variant EMA sweep with the same frozen dataset and strategy family. | Shows whether the workload grows predictably once there are enough variants to amortize setup cost. |
| 500 variants cold median | 752.54 ms | Elapsed time to compute the full 500-variant EMA sweep in the Node/service path. | Checks the middle of the scale curve before the largest run. |
| 1000 variants cold median | 1559.96 ms | Elapsed time to compute the full 1000-variant EMA sweep in the controlled Node/service boundary. | This is the headline scale result, but it excludes UI rendering and external data fetching. |
| 1000 variants per-variant median | 1.35 ms | Median cost per strategy variant inside the 1000-variant cold sweep. | Explains whether adjacent strategy exploration remains practical as the variant count grows. |
Production-like Builder render harness
Builder UI latency
Uses the real BacktestDashboardChartComponent and production chart, metrics and trades components. It excludes auth, Apollo subscriptions and external fetch.
benchmarks/results/builder-production-like-production/2026-07-26T22-25-07-155Z/benchmark-matrix.md
| Statistic | Value | What it measures | Why it matters |
|---|---|---|---|
| Cold initial presentation-ready median | 33.6 ms | Time from the benchmark action until computed results are available to the UI layer for the first measured scenario. | Separates data/result readiness from visual rendering cost. |
| Cold initial fully-rendered median | 258.3 ms | Time until the chart, markers, trades and metrics are all ready in the production-like harness. | This is the closest current user-facing latency signal, while still excluding auth and network fetch. |
| Warm identical fully-rendered median | 241.7 ms | Fully rendered latency for an identical rerun with reusable work available. | Shows whether rerendering the same strategy remains stable under cache reuse. |
| Operator-change fully-rendered median | 241.6 ms | Fully rendered latency after changing a comparison operator in the strategy. | Represents a realistic lightweight edit during strategy exploration. |
| Pair-return fully-rendered median | 241.4 ms | Fully rendered latency when returning to a previously opened pair. | Checks whether navigation back to a known analytical view remains responsive. |
Workflow references, not pure engine comparison
Freqtrade boundary references
The point is boundary clarity: process startup, imports, config loading and result parsing are separated from backtesting work where possible.
docs/benchmarks/results/controlled-ema-freqtrade-boundaries-v1.md
| Statistic | Value | What it measures | Why it matters |
|---|---|---|---|
| 2Signals in-process workflow | 20.25 ms | Median total workflow time for 10 EMA variants inside the 2Signals in-process benchmark boundary. | Provides the local in-process reference for the same strategy family and dataset. |
| Freqtrade --strategy-list workflow | 5.51 s | Median total workflow time for Freqtrade using one process with multiple strategies passed via --strategy-list. | This is the closest natural Freqtrade batch boundary found so far without building a custom persistent worker. |
| Freqtrade separate-process CLI workflow | 35.52 s | Median total workflow time when each Freqtrade strategy variant runs through a separate CLI process. | Captures the cost of repeated process startup and CLI workflow overhead. |
| Correctness status | passed | All three boundary references passed the declared controlled correctness gate. | Prevents presenting timing numbers when the compared outputs do not match. |
Controlled local frozen futures boundary
Complex futures correctness
This is the most useful non-trivial correctness artifact right now. It checks a complex futures setup rather than another tiny EMA-only example.
docs/benchmarks/results/controlled-complex-current-engine-export-v1.md
| Statistic | Value | What it measures | Why it matters |
|---|---|---|---|
| Dataset size | 181,447 5m candles across 7 pairs | Frozen market-data scope used by the complex futures comparison. | Shows the comparison is not limited to a tiny EMA-only fixture. |
| Indicator values compared | 2,903,152 | Per-candle indicator values compared between the controlled outputs. | Checks that the computational foundation of the strategy matches before looking at trades. |
| Mask values compared | 725,788 | Entry and exit boolean mask values compared across the complex strategy boundary. | Signals depend on masks, so mask agreement catches semantic differences before trade simulation. |
| Compared trades | 123 | Trades compared between the current 2Signals export and the frozen Freqtrade reference. | Trade-level parity is the practical output users care about. |
| Mismatched fields | 0 | Compared trade fields that differed in the declared controlled boundary. | The strongest current correctness signal for a non-trivial strategy sample. |
Tests
The important workflow is rerunning benchmarks, not generating documents.
These commands are the ones that matter when checking the technology. The whitepaper should summarize their output, not become a separate build system.
| Command | Purpose |
|---|---|
| pnpm bench:compare:ema:2signals-scale:correctness | Checks dataset correctness once and strategy correctness across the controlled EMA scale variants. |
| pnpm bench:compare:ema:variant-scale:matrix | Builds the neutral side-by-side EMA scale matrix for 2Signals and Freqtrade boundaries. |
| pnpm bench:compare:ema:freqtrade-persistent-variant-scale | Runs the closest natural Freqtrade strategy-list boundary for 10 EMA variants. |
| pnpm bench:equivalence:complex:current-engine-export:controlled | Runs the complex futures current-engine export comparison against the frozen Freqtrade reference. |
| pnpm bench:builder:production | Runs the production-like Builder render benchmark with the current production build flow. |
Correctness first
Results matter only with correctness gates: dataset identity, indicator series, masks, signals, trades, fees and P/L.
Boundary clarity
Every timing result names its boundary. Node/service, Builder render and Freqtrade CLI runs are different things.
No overclaiming
Cache and memory claims stay diagnostic until a real eviction policy and broader browser/device matrix exist.