Overview
These benchmarks show how quickly the TypeScript and Go SDKs evaluate flags locally, and how quickly configuration changes reach the TypeScript SDK. Measurements were recorded on October 15, 2026 (UTC) using a small production snapshot and synthetic evaluation contexts. They describe the tested workload and hardware, not a performance guarantee or latency SLO.Evaluation latency and throughput
Flag checks read an in-memory snapshot without a network request. The table measures public SDK calls with evaluation events disabled. Startup, snapshot download, parsing, and refresh are excluded.
Workload labels describe the configured rules. Which rules execute depends on the evaluation context and the first matching rule; these results do not cover every targeting path or rule count.
Latency percentiles come from individually timed calls and include timer overhead. TypeScript reports the median of five trial percentiles; Go latency comes from one pass. Throughput is measured separately and reports the median of five trials. It is not calculated from p99 latency.
Evaluation while configuration updates
A separate stress test repeatedly replaced snapshots while evaluations continued. It used the same six boolean flags as the evaluation run, including a second flag without targeting rules. Refreshes used an in-process transport to isolate replacement behavior from network latency.
Each range contains the per-flag p99 values; it is not a percentile pooled across flags. The first TypeScript call after applying a snapshot was slower than steady-state calls in this run.
JavaScript evaluation and snapshot application share one thread, so the test yielded between batches to allow updates. Go refreshed in a background goroutine. Both tests used one evaluation caller; they do not establish scaling across many concurrent callers.
Configuration freshness
The production test changed an isolated boolean flag ten times and measured when the SDK applied the new snapshot and returned the new value.
The default polling interval is 30 seconds. The polling result above uses an explicitly configured 1-second interval; it does not describe default polling freshness. The default interval was not measured in this run.
Timing includes the configuration API request, publication, notification or polling, snapshot fetch, and application. The WebSocket test disabled polling fallback. Both paths were measured through the TypeScript SDK; Go currently refreshes through polling or manual refresh.
Ten samples give an initial observation, not reliable p95 or p99 propagation estimates. See Snapshots for how updates reach your application.
Measurement conditions and limits
- Hardware: Apple M5 Pro with 18 logical CPUs; Node.js 26.11.1 and Go 1.26.2.
- Workload: Six boolean flags with up to two rules, five compiled audiences, and 64 rotating, preallocated synthetic contexts with two attributes each. The tables show five representative flag workloads. Variant, number, and JSON flags were not measured.
- Sampling: TypeScript latency used 50,000 calls per flag in each of five trials. Go latency used one 50,000-call pass per flag. Throughput used five trials per SDK, with warmup before measurement. Go throughput used
GOMAXPROCS=1; the separate latency and replacement pass used the runtime default. Neither SDK was pinned to a physical CPU. - Replacement test: TypeScript measured 102,400 calls and 100 replacements per flag, with about 100 first-call-after-application samples. Go measured 50,000 calls and observed 8–16 background replacements per flag.
- Environment: Measurements ran on a developer machine, and propagation testing overlapped part of the evaluation run. Submicrosecond timings are sensitive to timer resolution, runtime optimization, garbage collection, and scheduling.