Engineering work
Developer toolingOpen-source package

bigocheck

A zero-dependency empirical Big-O checker that turns performance expectations into CLI and pytest assertions.

PythonCLIpytestEmpirical analysisCI

01

Problem

Algorithmic complexity is often reviewed informally, so regressions surface only after realistic workloads become slow or expensive. Teams need a lightweight way to make growth-rate expectations repeatable in local development and CI.

Constraints that shaped the design

  • Keep the core package zero-dependency.
  • Support both exploratory CLI use and enforceable pytest workflows.
  • Communicate the limits of empirical inference instead of presenting it as formal proof.

02

Architecture

  1. 01

    Generate observations

    Run a target over controlled input sizes and collect timing behavior.

  2. 02

    Fit growth models

    Compare observations with candidate complexity curves and confidence guardrails.

  3. 03

    Enforce expectations

    Expose results through a CLI, Python assertions, and pytest integration.

03

Design decisions

  • Optimize for a small adoption surface by avoiding runtime dependencies.
  • Provide assertions so performance expectations can live beside functional tests.
  • Use explicit thresholds and controlled data generation to reduce false confidence.

04

Alternatives considered

  • Relying only on post-hoc profilers after a regression is already visible.
  • Treating a single timing measurement as proof of asymptotic behavior.
  • A heavyweight benchmarking stack for a focused CI guardrail.

05

Testing and results

  • The repository exposes the implementation, usage, tests, and release history.
  • The PyPI artifact provides an independently installable package surface.
  • The tool is framed as empirical evidence with configurable guardrails, not formal complexity verification.

Outcome

bigocheck moves a common performance-review conversation into a reusable, automatable developer workflow.

06

Limitations

  • Empirical timing is sensitive to workload design, environment noise, and threshold selection.
  • The result supports engineering decisions but does not replace mathematical analysis.

07

Lessons learned

  • Performance checks are most useful when they run early and explain their confidence boundaries.
  • Small developer tools earn trust through transparent limits and low adoption cost.