About

Optimizing code is not just about brevity; it is about architectural scalability. As datasets grow from thousands to billions of records, the difference between linear O(n) and quadratic O(n²) logic can mean the difference between a sub-second query and a server timeout. This tool performs static analysis on your source code to estimate its Big O complexity based on control flow nesting and recursion patterns.

We parse the logical depth of your loops, functional iterators (like .map or .reduce), and recursive calls. Note that this is a static heuristic analyzer - it does not execute your code, thereby ensuring 100% security, but it may interpret certain obscure syntactical sugars differently than a runtime profiler.

Formulas

The asymptotic time complexity is generally approximated by the Dominant Term of the instruction count function f(n). If we analyze the nesting depth of code blocks:

T(n) ≈ O(n^k)

Where k represents the maximum depth of loop nesting found in the Abstract Syntax Tree (AST). For divide-and-conquer algorithms, we observe the Master Theorem pattern:

T(n) = aT(nb) + f(n)

We flag code sections where k ≥ 3 or where functional recursions are detected without clear base cases.

Reference Data

Complexity Class	Name	Operations for N=100	Use Case
O(1)	Constant Time	1	Hash Map Lookup
O(log n)	Logarithmic	7	Binary Search
O(n)	Linear	100	Simple Iteration
O(n log n)	Linearithmic	664	Merge Sort, Quick Sort
O(n²)	Quadratic	10,000	Nested Loops
O(2ⁿ)	Exponential	1.26 × 10³⁰	Recursive Fibonacci
O(n!)	Factorial	∞	TSP Brute Force

Frequently Asked Questions

These methods iterate over the entire array implicitly. If you place a .map() (O(n)) inside a for-loop (O(n)), you are effectively creating a nested loop structure, resulting in O(n²) complexity, even if you don't see braces { }.

We detect function declarations that call themselves. While we can flag "Recursion", accurately determining if it is O(log n) or O(2^n) via static analysis requires knowing the branch factor and reduction rate, which is often ambiguous without execution. We flag it for manual review.

Constant operations (math, variable assignment) do not increase the Big O class. However, we track "Anti-Patterns" like heavy console logging or DOM manipulation inside loops, which - while technically O(1) in algorithmic theory - are incredibly slow in practice due to I/O blocking.

No. Space complexity (memory usage) and code readability are vital. A highly optimized O(1) algorithm that is unreadable is arguably worse than a clear O(n) one for small datasets. This tool focuses strictly on time complexity scalability.