The 300ms Rule for Micro-benchmarking

Published: October 5, 2026

When conducting a micro benchmark, a common question arises: What is the ideal duration for a test run?

My personal heuristic is to adjust the size of the input data until the execution time settles at approximately 300ms. This specific target is chosen for several technical and psychological reasons.

Technical Justifications

Using milliseconds as the primary unit provides a "sweet spot" for data representation:

• Readability: Values between $1$ and $999$ are simple integers. They offer sufficient granularity to detect minor optimizations while remaining easy to scan.
• Uniformity: It eliminates the need for floating point decimals or switching between different units (e.g., comparing 239ms to 1.31s is mentally clunkier).

Furthermore, the duration helps mitigate noise:

1. Avoiding Fixed Costs: Runs shorter than 10ms are often contaminated by "cold start" overheads, such as interpreter initialization.
2. Robustness: In computing terms, several hundred milliseconds is an eternity. This duration ensures that one-off system spikes become irrelevant, removing the need for complex, fragile accounting techniques.

The Human Element

Beyond the numbers, this range aligns with human perception:

• Intuitive Feel: Because hundreds of milliseconds are perceptible to a person, I can rely on my internal sense of time rather than just raw numeracy.
• The "Instant" Effect: There is a distinct satisfaction in seeing a CLI tool transition from a noticeable lag to feeling "instant" after an optimization.

However, exceeding the one-second mark is counterproductive. If a benchmark takes too long, the iteration cycle slows down. For example, if you want to check for variance by running the test 10 times, you want that process to be snappy.

Summary Comparison

Workflow Logic

Implementation Checklist

• Select input data
• Run initial test
• $\text{Adjust } N \text{ until } \text{time} \approx 300\text{ms}$
• Run 10x to eyeball variance

Example Mock-up

# Example of adjusting input size for the 300ms target
def benchmark(data_size):
    start = time.perf_counter()
    process_data(data_size)
    end = time.perf_counter()
    return (end - start) * 1000 # Convert to ms

# Target: ~300ms
print(f"Execution time: {benchmark(10000)}ms")

The Core Philosophy: The goal here is not to achieve a scientifically perfect measurement of performance. Instead, the objective is to provide the developer with enough intuition to make an informed engineering decision.