Timeouts and rate limits in an online playground

Shared compute is a commons. Without timeouts and rate limits, one runaway loop or automated hammer can degrade the experience for everyone and inflate infrastructure cost.

Code Arena’s limits are not a puzzle to bypass. They are a contract: bring short, intentional work; get a fast answer; leave the machine ready for the next person.

If your program does not finish within the allowed window, the sandbox stops it. Infinite loops, accidental O(n³) on big n, and busy-waiting are the usual suspects.

Empty Output plus a failure message is a clue: the process may have been busy without printing. Add progress logs or shrink the workload until you see activity.

If you click Run rapidly, automate submissions, or share a page that auto-runs too aggressively, you may see a “try again later” style response. Wait for the retry window, then continue with fewer, more deliberate runs.

Teaching tip: ask students to predict Output before they Run. Fewer speculative clicks means fewer throttles and better thinking.

Replace while True with a bounded loop. Cap recursion depth. Process a sample of data instead of a whole scraped corpus. Log once per stage, not once per million iterations.

• Use range(n) / for loops with known bounds
• Early-return when you already have the answer
• Test algorithms on n=10 before n=10_000_000
• Avoid sleep-based “timing demos” in sandboxes

Move to a local machine, a batch job, or a dedicated notebook environment. Playgrounds are for clarity and communication; clusters and workstations are for throughput.

If your goal is to learn Big-O, measuring tiny n with clear counters is often more educational than melting a shared VM.

In any language editor, write a loop that prints 20 lines, then a version that would run unbounded. Run the safe one. Discuss (or journal) how you would detect the unsafe one before pressing Run.