# How fast is my solution

> The percentile beside an accepted submission, the growth analysis that runs it at four input sizes, and why neither of them ever prints a Big-O.

Source: https://www.revquix.com/docs/practice/how-fast-is-my-solution
Last verified: 2026-09-04

---

Once a submission is accepted, two different things can tell you something about its speed. Both are
measurements. Neither is an analysis of your code, and that distinction is the whole design.

## The percentile

Beside an accepted submission you may see how its runtime compares with other accepted submissions
on the same problem.

Two rules make that number worth reading:

- **It is always within one language.** Java against Java, C++ against C++. Comparing across
  languages would tell every Java user they are slow forever for writing correct code.
- **It is hidden until there is enough to compare against.** "Beats 100% of submissions" when yours
  is the only one is a joke, and it costs trust in every other number on the page.

So a missing percentile on a new problem is expected.

## Analyse my solution

The second one is opt-in. On an accepted submission you may find an **Analyse my solution** button.
It runs your accepted code again at four increasing input sizes, times each, and reports what
happened to the clock.

You get the four sizes, the four times, and a sentence:

> Your solution's runtime roughly quadrupled when the input doubled.

That sentence is true, it is falsifiable against the numbers printed beside it, and it teaches the
idea better than a symbol does.

### What the answers can be

| Result                   | What was observed                                                                                                                       |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
| **Flat** / **Sublinear** | Time barely moved as the input grew.                                                                                                    |
| **Linear**               | Doubling the input roughly doubled the time.                                                                                            |
| **Indistinguishable**    | Between linear and n log n - at these sizes they differ by less than the noise, so we say so rather than pick one.                      |
| **Quadratic**            | Doubling the input roughly quadrupled the time.                                                                                         |
| **Cubic or worse**       | It grew faster than quadratically.                                                                                                      |
| **Too fast to measure**  | Every size finished so quickly that the timings are mostly overhead. Not a verdict on your solution - the measurement could not see it. |
| **Not enough data**      | Too few sizes completed to fit anything.                                                                                                |

> **Warning** - This panel never prints a Big-O, and that is on purpose
>
> Deciding a program's asymptotic complexity automatically is not merely hard - it is impossible in
> general. Anything claiming to do it is guessing, and `O(n²)` printed next to `Runtime: 4 ms` reads
> like a measurement when it is not.
>
> The complexity the _author declared for the problem_ is a different thing, and it does appear as a
> symbol - on [the Approach tab](https://www.revquix.com/docs/practice/hints-and-approach). Declared,
> not discovered.

### When the button is not there

It is **absent rather than disabled** when the problem cannot be profiled. Measuring needs an input
generator written by the problem's author in your language, and most problems will not have one for
a long time. Rather than offer a button that spends a sandbox slot to produce a failure, we do not
draw it.

It is also only offered on **accepted** submissions. Profiling a wrong answer measures how fast it
is wrong.

### It measures once

A finished analysis is stored and shown again without re-running anything. Your source has not
changed, so re-measuring would spend a run to produce the same number plus the noise of a shared
machine - and would show you two different slopes on two visits, which teaches that the measurement
is arbitrary.

If the problem's test cases change afterwards, the stored analysis is marked stale.

> **Note** - If your solution throws during the analysis, that is a real finding
>
> The generated inputs are larger than the problem's own cases. Code that passes every test and falls
> over at n = 8,000 has a bug the test cases did not reach, and the panel shows the error.

## Related

- [Languages and limits](https://www.revquix.com/docs/practice/languages-and-limits) - Why the same algorithm times differently per language.

- [Asking AI for help](https://www.revquix.com/docs/practice/asking-ai-for-help) - The opinion, to check against this measurement.