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.
debug:
0.33s user 0.01s system 98% cpu 0.349 total
release:
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 
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: https://godbolt.org/g/29MrHv
Specifically:
example::sum_from_to:
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
.LBB9_2:
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
.LBB9_4:
mov eax, dword ptr [rbp - 60]
add rsp, 80
pop rbp
ret
.LBB9_5:
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
.LBB9_7:
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 
Any updates concerning the compilation with optimization ?
By the way which version of rust is used ?
Any update?
Hi,
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!
Thanks.
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 
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”.
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.