Efficio measurement-honest code optimisation Optimise a file
Python · one file · measured on a machine of its own

Make your code faster —
and know that it actually is.

Send a Python or C++ file and the tests that exercise it. Efficio rewrites the code, proves the rewrite still passes your tests, times both versions against each other on a machine doing nothing else, and emails you the improved file with a full report of how it knows.

It will also tell you, plainly, when it found nothing. That is the point: a speed-up you cannot trust is worse than no speed-up at all.

+38.7%
faster, on the example below
0.45%
that machine's noise floor
P = 1.000
confirmed at full fidelity
~10 min
one dedicated cloud VM
How it works

Five stages, and your code is never touched

Nothing is guessed and nothing is applied on your behalf. The submission runs on a throwaway virtual machine that is destroyed when the job ends.

1

It watches your tests run

Your file ships no benchmark, so Efficio runs your suite once and records what it actually calls, with what arguments. That recording becomes the timed workload.

2

It proposes rewrites

A catalogue of transformations — hoisting work out of loops, replacing quadratic string building, turning membership tests into sets — applied exhaustively, not sampled.

3

Your tests are the gate

Every candidate must pass your tests before anything is timed. A rewrite that changes an answer is discarded for free, having cost no measurement at all.

4

It measures, carefully

Survivors are screened cheaply, then narrowed, then confirmed — winner and original interleaved on one quiet machine, so drift hits both arms equally.

5

You get a file and a report

The improved file, the diff, the measured numbers and the judgement — as a PDF in your inbox. You decide what to do with it.

✓

Nothing is committed

No pull request, no push, no write-back. Efficio recommends; a human applies. That property is what makes every other claim here checkable.

A real result

Faster on one axis, worse on another — and told so

A function building a string with += in a loop, submitted with a test that exercises it over 4,000 rows. Measured on one 8-core cloud machine. This is a real run, not an illustration.

Two panels, never two bars on one axis: 38% and 587% share no scale, and a second y-axis is the commonest way a chart misleads. Each panel is a before/after pair against its own baseline of 100.

The verdict was review, not a win

38.70% faster by a margin the machine can clearly see — and it allocates nearly seven times the memory. A latency-only tool calls that an unqualified win and moves on. Efficio hands you both numbers and refuses to decide for you. 

  def render_rows(rows):
      """Render rows as a newline-terminated block."""
-     out = ""
-     for row in rows:
-         out += row + "\n"
+     out = "".join(row + "\n" for row in rows)
      return out
Why trust it

What would have to be true for the number to be a lie

Most tools report a speed-up. The interesting question is how it could be wrong — these are the answers, and each one is a mechanism rather than a promise.

  • Every number carries its resolution. A machine can only see differences bigger than its own noise. A rewrite 0.3% faster on a host that resolves 1% is reported as unresolved — never as a win.
  • One measurement at a time. Two benchmarks on one machine are each other's noise. Your job gets a machine to itself, which is why it takes minutes.
  • Correctness is settled before speed. The gate that runs your tests takes no timings, and the timer never runs on code that failed them.
  • Two axes, not one. Latency and memory are both reported. Faster and hungrier is not called a win — you are told, and you choose.
  • Work that vanishes is caught. A rewrite that gets 20,000× faster usually means the compiler deleted the work. That is detected and refused, not published.
  • "Found nothing" is a real answer. Efficio regularly searches and confirms nothing. It says so instead of manufacturing a number.
Reading the result

Four outcomes. Only one is an unqualified recommendation.

Whichever you get, the reasoning arrives with it.

Adopted

Confirmed faster, by more than the machine could resolve, and no worse on memory. Take it.

Review

Confirmed faster, with a caution attached — usually memory. Real, and yours to judge. You still get the file.

No change

It searched and confirmed nothing worth having. Common, and honest.

Could not measure

Usually tests that never call the code, or call it on inputs too small to time.

Try it

Send a file and its tests

The tests decide whether anything can be measured. Efficio times what your tests actually call, so they must exercise the real path at a realistic size — a function invoked twice with two items finishes far below the clock's resolution and comes back “could not measure”. Include one test that runs it over thousands of items.

Limits

What it cannot do yet

Stated plainly, because a tool that hides its limits is asking you to find them in production.

  • Python only, one file at a time. Efficio also has JavaScript and C++ engines; this page does not expose them.
  • Packages are installed, but only from PyPI by name. List them and they are installed on the measuring machine first; URLs, git repositories and local paths are refused, and the install counts against the run's time budget.
  • It optimises what your tests exercise. If they do not call the slow path, or call it on toy inputs, there is nothing to measure — and it will say so rather than guess.
  • Energy is reported, never optimised. It is modelled on this hardware, not metered, and is labelled as such.
  • A review verdict is not a recommendation. It is a measured result with a caution attached, handed to you because you are the one who knows whether the trade is acceptable.