Evaluation Cost Breakdown
Troubleshooting reference for Statsig evaluation scoring messages in the console, including diagnostics for SDK health and evaluation correctness.
The overall complexity of all rules in a gate determines feature gate evaluation speed. Each condition, operator, and value count contributes to a score that classifies rules and gates as Normal, Slow, or Very Slow. The gate complexity is the sum of the complexity of all its rules. A gate can be slow even without a single slow rule if the combined rules exceed the threshold. Use this page to identify the likely cause of a slow gate and the fastest way to fix it.
How to interpret "Slow" and "Very Slow"
These labels are relative tiers, not fixed millisecond thresholds. Actual runtime depends on device or server, network, and whether the SDK is using the worst-case scenario (for example, even if country is included in the user object, the SDK assumes IP geolocation is required). These labels are warnings. If you're already using the best practice for your context, you can ignore them.
Quick diagnosis
| What you see | Likely cause | Fastest fix |
|---|---|---|
| Gate targets OS/Browser/Version and is slow | User-agent parsing at evaluation time | Pass os_name, os_version, browser_name, browser_version (server) or systemName, systemVersion, browserName, browserVersion (client) directly on StatsigUser |
| Gate targets Country and is slow | IP geolocation lookup | Pass country directly on StatsigUser |
| Gate uses large ID lists (overrides or ID based segments) | Large list lookup | Trim stale IDs, split lists, or move to conditional segments or a custom attribute |
| Gate uses Regex or Version String operators | Expensive per-check parsing | Replace with exact matches or precomputed attributes |
| Gate has many nested Passes Gate/Segment rules | Costs compound across nested evaluations | Reduce nesting or push logic into a single gate/segment |
| Conditions have many values (50+) | Large value scans | Prune values, split cohorts, or move to a smaller segment |
Cost drivers and fixes
Conditions
Statsig applies evaluation costs based on the condition type used in a gate. This table lists only conditions with a significant impact. Conditions not listed don't significantly impact SDK evaluation speed.
| Condition | Impact (assuming worst case) | worst case | Reason |
|---|---|---|---|
| BROWSER | medium | user agent | Requires user agent parsing unless Browser is explicitly provided |
| BROWSER VERSION | medium | user agent | Requires user agent parsing unless Browser Version is explicitly provided |
| OS | medium | user agent | Requires user agent parsing unless Operating System is explicitly provided |
| OS VERSION | medium | user agent | Requires user agent parsing unless OS Version is explicitly provided |
| COUNTRY | Low | IP lookup | Requires IP-based geolocation lookup when country isn't explicitly set |
| PASSES SEGMENT | high | deeply nested / large segment | complexity dependent on cost of nested segments |
| FAILS SEGMENT | high | deeply nested / large segment | complexity dependent on cost of nested segments |
| PASSES GATE | high | deeply nested with slow gates | complexity dependent on cost of nested gates |
| FAILS GATE | high | deeply nested with slow gates | complexity dependent on cost of nested gates |
Tips:
- If you target OS/Browser or their versions, pass explicit values on
StatsigUserto avoid user-agent parsing. Server SDKs supportos_name,os_version,browser_name, andbrowser_version; client SDKs usesystemName,systemVersion,browserName, andbrowserVersion. - If you target Country, pass
countrydirectly to avoid IP-based lookup.
ID list size (overrides and ID based segments)
ID lists directly affect evaluation performance. This applies to both ID list overrides and segment conditions that reference ID lists.
| ID List Size | Impact |
|---|---|
| 1,000+ IDs | High |
| 10,000+ IDs | Very High |
Tips:
- Trim stale IDs and scope lists to active cohorts.
- Split large lists into smaller, purpose-built cohorts.
Operator
Statsig applies costs based on the operator used in a condition. Operators not listed don't significantly impact SDK evaluation speed.
| Operator | Impact | Reason |
|---|---|---|
| Any of (Case Sensitive) | Low | Requires explicit equality comparison |
| None of (Case Sensitive) | Low | Requires explicit inequality comparison |
| Match Regex String | Medium | Requires regex matching |
| Version String | Medium | Requires semantic version comparison |
| Array Contains Any / None / All | Low | Requires array scan |
Tips:
- Match Regex String: Replace with
ANY OFor precompute a boolean/enum attribute. - Version String: Precompute a normalized numeric value or
major/minorfields and compare those instead. - Array Contains: Keep arrays short and consider flattening frequent checks into a single boolean attribute.
Value count
Statsig applies costs based on the number of values provided to a condition.
| Entity | Impact |
|---|---|
| 10–19 values | Low |
| 20–29 values | Low |
| 30–49 values | Medium |
| 50+ values | High |
Tips:
- If you're in the 50+ range, prune stale values or split cohorts.
- Consider moving large lists into a smaller inline segment or a custom attribute computed upstream.
Was this helpful?