Rust compiled in debug mode

Rust should be compiled with optimisation. If you stick with rustc, just pass -O to the compiler. If you move to cargo, just make sure to pass --release to cargo…

Running time are hugely bigger in debug mode with rust (way bigger than with c++) making any puzzle with some computation very hard to solve with reasonable code.


+1. This must be fixed. (I believe it’s really easy fix to add a cmd parameter).


My program for “smash the code”. One turn.

0.33s user 0.01s system 98% cpu 0.349 total
0.02s user 0.00s system 94% cpu 0.028 total


The difference between debug and release is really huge. Please compile in release!


Using rust in debug mode is like writing code with the complexity of C++ and the performance of Python. Please fix this :smiley:


Any update about enable the flag “-O” ?
Is it planned or not ?


I asked a member of CG staff directly recently, and it turns out that they are currently trying to overhaul the compile/execution system. So whilst they aren’t currently planning to do this directly, there is hope for more flexible compilation in future.

Also, I’ve started a project to bundle up my own rust project codebases for cg puzzles/games into a single file for CG, and plan to find ways to perform optimisations in the bundler that improve the code’s performance on CG (a friend has some ideas for it, as well). I shared it with this topic.


Has there been any progress with allowing optimization for Rust code?

Rust in debug mode is really slow and will ignore inline directives. Even the lowest optimization level would fix that without blowing up compile times too much, though of course higher would be better.

Compiling all code with optimizations is not desirable, though, since debug mode has a lot of useful checks like integer overflow checks. A kind of a flag to tell whether you want it in debug mode or not is needed, which could just be a special comment, as long as it’s documented properly. (maybe in the template?)

Maybe something like:

// CodinGame: extra-compiler-flags: -C opt-level=3

This could then be extended for other languages and runtime parameters, if needed.

I prefer using a comment here because you actually can package it with the code, unlike a checkbox or such. A (minor?) challenge here is documentation.

If it’s not preferred to give coders that much power, you could limit the options to something like:

// CodinGame: compile-release-mode: true



Really want to see this. Would like to use this site to practise Rust and it’s fine for the practise exercises but for anything competitive it will fall short without optimisations. “Zero-cost”/compile-time abstractions are idiomatic in Rust, to the point that the for-loop only works via iterators, which should be compiled away in simple scenarios.


In debug mode, not even the range iterators get optimized away, you end up with explicit monomorphised calls to IntoIterator::into_iter and Iterator::next. As you can see here:


        push    rbp
        mov     rbp, rsp
        sub     rsp, 80
        mov     dword ptr [rbp - 60], 0
        mov     dword ptr [rbp - 56], edi
        mov     dword ptr [rbp - 52], esi
        mov     esi, dword ptr [rbp - 56]
        mov     edi, dword ptr [rbp - 52]
        mov     dword ptr [rbp - 32], esi
        mov     dword ptr [rbp - 28], edi
        mov     rdi, qword ptr [rbp - 32]
        call    <I as core::iter::traits::IntoIterator>::into_iter
        mov     qword ptr [rbp - 16], rax
        mov     rax, qword ptr [rbp - 16]
        mov     qword ptr [rbp - 24], rax
        mov     esi, dword ptr [rbp - 24]
        mov     ecx, dword ptr [rbp - 20]
        mov     dword ptr [rbp - 64], esi
        mov     dword ptr [rbp - 68], ecx
        mov     eax, dword ptr [rbp - 64]
        mov     dword ptr [rbp - 48], eax
        mov     ecx, dword ptr [rbp - 68]
        mov     dword ptr [rbp - 44], ecx
        lea     rdi, [rbp - 48]
        call    core::iter::range::<impl core::iter::iterator::Iterator for core::ops::Range<A>>::next
        mov     qword ptr [rbp - 8], rax
        mov     rax, qword ptr [rbp - 8]
        mov     qword ptr [rbp - 40], rax
        mov     eax, dword ptr [rbp - 40]
        test    eax, eax
        jne     .LBB9_5
        jmp     .LBB9_4
        mov     eax, dword ptr [rbp - 60]
        add     rsp, 80
        pop     rbp
        mov     eax, dword ptr [rbp - 36]
        add     eax, dword ptr [rbp - 60]
        setb    cl
        test    cl, 1
        mov     dword ptr [rbp - 72], eax
        jne     .LBB9_7
        mov     eax, dword ptr [rbp - 72]
        mov     dword ptr [rbp - 60], eax
        jmp     .LBB9_2
        lea     rax, [rip + panic_loc.4]
        mov     rdi, rax
        call    core::panicking::panic@PLT

I coded Minimax for Wondev Woman in rust but I cannot run a depth of more than 2. Resulting in a very bad AI :frowning:

Any updates concerning the compilation with optimization ?
By the way which version of rust is used ?


Any update?



Is there any news on this subject ?
I would like to use Rust for the next contest but if the performances are not up to it I should stop learning Rust right now!


1 Like

Sorry for the lack of information. Unfortunately, we won’t be tackling optimization flags before next year. First, we are updating all the languages versions.

Ok thanks for the info, let’s look at some C++ then :slight_smile:

Any news ?


Please fix this, I had to junk my entire strategy (and several days of work) for botters due to the huge overhead of debug mode. It’s just one flag to add to the compilation command after all.


Hey tha’ts exactly what we said about O3 and C++. This was 2 years ago. We still don’t have O3. Have fun.

Troll aside, i’m not sure why codingame refuse to touch at compilation/run command line even when all the community is asking for it. This issue is not specific to Rust, many langages share the same (bad compilation/run command line).

Most of the time, Codingame argument is “if we change the command line, many current working codes will not work anymore and we don’t want it”.

1 Like

For clarification though, some things in Rust are SLOW in debug mode. Like python and ruby run rings around it, its very stupid. There are clash of code challenges etc, even very very simple challenges, where debug mode Rust just actually can’t deliver the answer in the allotted time, especially without rewriting all the IO code provided as a start. Honestly its pretty stupid just how slow Rust debug mode is relative to its release performance but yea, normally who cares, just compile in release mode…

The IO stuff for example on botters with the default code was taking me over 40ms, up to like 42, leaving 8ms to actually solve the problem else timeout.


well, that argument is obviously completely bogus, just saying.

1 Like