What happens when my program runs out of cycles, and how do I make it faster?

What happens when you run out

Nothing breaks. The tick simply ends at that point in your code. Your program picks up from there next tick, but its readings are now a tick old, so the bot reacts to where things were rather than where they are. A program that regularly overruns makes slow, stale decisions.

Ending a tick early with wait() (or loop() or Update() returning, in C++ and C#) gives up the cycles you don't need. That's normal and costs you nothing.

Measure it

• After a test, the Match panel beside the Arena's field lists each bot's average cycles per tick (and any faults).
• In your code, cpu.cycles (in Python; see the Reference for your language) is the number of cycles left in this tick. Use it to skip optional work when time is short:

if cpu.cycles > 200:
    log("{} cycles to spare", cpu.cycles)

• In Brain code, the Machine panel below the editor shows your CPU's cycles per tick and I/O per loop: the fixed cost of reading and sending to the parts each loop, which grows with the parts on the machine.
• Generated assembly shows the CPU code your program became. A loop that turns into many lines of it is a good place to look.

Logs are free: they cost no cycles, so log as much as you like while you measure.

Make it cheaper

• Don't redo work every tick that only needs doing now and then. Use cpu.tick (20 a second) to run it every few ticks, for example if cpu.tick % 10 == 0:.
• Read a list reading (a camera's or a radar's, say) once a tick and keep it in a variable, as the Reference advises.
• Keep loops short and leave them as soon as you have your answer.
• Run a test after each change and compare the cycles per tick.

Running out of memory

The status line under the editor shows how many ROM words (program) and RAM words (data) your program uses, out of how many. A bigger ROM part on the machine gives more ROM: a ROM-M twice the small one's, a ROM-L four times.