Languages and limits
The five languages you can solve in, the time and memory your code gets, why Java starts with less of the budget, and the one thing TypeScript does differently.
Five languages: Java, C++, Python, JavaScript and TypeScript. Which of them a given problem offers is up to its author - the picker lists only the ones with a working stub and a verified reference solution.
Time#
A whole submission gets five seconds, and that is a hard ceiling on the sandbox rather than a per-problem setting anyone can raise. Every test case in the submission runs inside that one budget, in a single process - which is why a problem with forty cases is not forty times slower to judge than one with two.
Compilation is timed separately and more generously.
Memory#
Each language gets its own ceiling, sized to what it actually needs: Java and TypeScript get the most, C++ and Python less, because they need less to do the same work.
This is also why "beats X% on memory" is never compared across languages. Java reports around 48 MB where C++ reports 7 MB for identical work, so a cross-language ranking would tell every Java user they are in the bottom decile forever for writing correct code.
Size#
- Your source is capped at 64 KB. No solution to a practice problem approaches this.
- Output is capped, per attempt. A program that prints inside a hot loop gets cut off, and a very loud one is stopped with Too much output.
- Custom input you type into the Testcase pane is capped too, well above any hand-typed value.
Deep recursion works#
A recursive depth-first search over a large tree is ordinary, correct code, and on default settings it overflows the stack in both Java and C++. Both get a large stack here specifically so that it does not - hundreds of thousands of frames are fine.
If you hit Runtime error with a stack overflow, treat it as a real depth problem rather than a sandbox limit you cannot do anything about.
Per-language notes#
Your file is Solution.java. The code that calls it is a separate file, so compiler errors report
lines in your editor and nothing else.
The JVM startup cost described above is the only thing to keep in mind. Prefer StringBuilder over
repeated string concatenation in a loop, as you would anywhere.
C++17. Your code is compiled into one translation unit together with the driver, so you do not need
- and must not write - a
main.
Compilation is unoptimised, which is worth knowing if you are comparing runtimes against a local
build with -O2.
Your file is solution.py. Import what you need from the standard library as normal.
Python has no compile step, so the whole budget is available to your code - but the interpreter is slower per operation, so an algorithm that is asymptotically wrong will run out of time sooner here than in C++.
Your file is solution.js. Write class Solution { ... } - there is no need to export anything, and
the driver does not require your file.
A thrown error reports solution.js:4:18 - your own line and column.
Your TypeScript is genuinely type-checked, at ES2020, with real library types - Map, Set and
for...of over an iterable all work.
That is worth stating because it is not free: the sandbox's own TypeScript package compiles at ES5, where none of those work. The judge does the compilation itself instead, at a modern target, so the language you get is the one you expected.
A type error comes back as a Compile error in the compiler's own format -
solution.ts(3,15): error TS2322: ... - pointing at your line and column. A runtime throw reports
solution.ts:4:18.
What the sandbox does not have#
No network. Your solution cannot make an HTTP request, read a URL or reach anything outside its own process. Everything a problem needs is in its arguments.
No filesystem to speak of, and nothing persists. Each attempt starts clean.
Related#
Was this page helpful?