Allow compiling editor with target=release for aggressive optimization

[Calinou]

This keeps the required debug functionality enabled, but -O3 is used instead of -O2.

The resulting binary is a few megabytes larger, but there are non-negligible run-time performance gains, including editor startup and shutdown speeds.

Note: Binaries compiled with tools=yes target=release_debug will now use .opt.debug.tools suffix instead of .opt.tools. tools=yes target=release will use .opt.tools as before. Adjust your build/CI scripts accordingly.

Benchmark

Time to open and quit project manager

Without link-time optimization

❯ hyperfine -iw1 "bin/godot.linuxbsd.opt.tools.64 --quit" "bin/godot.linuxbsd.opt.debug.tools.64 --quit" 
Benchmark #1: bin/godot.linuxbsd.opt.tools.64 --quit
  Time (mean ± σ):      1.035 s ±  0.030 s    [User: 835.1 ms, System: 158.0 ms]
  Range (min … max):    1.010 s …  1.086 s    10 runs
 
Benchmark #2: bin/godot.linuxbsd.opt.debug.tools.64 --quit
  Time (mean ± σ):      1.082 s ±  0.023 s    [User: 873.1 ms, System: 156.3 ms]
  Range (min … max):    1.058 s …  1.120 s    10 runs
 
Summary
  'bin/godot.linuxbsd.opt.tools.64 --quit' ran
    1.04 ± 0.04 times faster than 'bin/godot.linuxbsd.opt.debug.tools.64 --quit'

With link-time optimization

❯ hyperfine -iw1 "bin/godot.linuxbsd.opt.tools.64 --quit" "bin/godot.linuxbsd.opt.debug.tools.64 --quit" 
Benchmark #1: bin/godot.linuxbsd.opt.tools.64 --quit
  Time (mean ± σ):      1.077 s ±  0.039 s    [User: 858.8 ms, System: 163.1 ms]
  Range (min … max):    1.034 s …  1.127 s    10 runs
 
Benchmark #2: bin/godot.linuxbsd.opt.debug.tools.64 --quit
  Time (mean ± σ):      1.109 s ±  0.018 s    [User: 882.2 ms, System: 167.3 ms]
  Range (min … max):    1.080 s …  1.130 s    10 runs
 
Summary
  'bin/godot.linuxbsd.opt.tools.64 --quit' ran
    1.03 ± 0.04 times faster than 'bin/godot.linuxbsd.opt.debug.tools.64 --quit'

Time to open and quit editor on empty project

Without link-time optimization

❯ hyperfine -iw1 "bin/godot.linuxbsd.opt.tools.64 /tmp/4/project.godot --quit" "bin/godot.linuxbsd.opt.debug.tools.64 /tmp/4/project.godot --quit"
Benchmark #1: bin/godot.linuxbsd.opt.tools.64 /tmp/4/project.godot --quit
  Time (mean ± σ):      3.442 s ±  0.371 s    [User: 2.358 s, System: 0.256 s]
  Range (min … max):    3.141 s …  3.918 s    10 runs
 
Benchmark #2: bin/godot.linuxbsd.opt.debug.tools.64 /tmp/4/project.godot --quit
  Time (mean ± σ):      3.675 s ±  0.448 s    [User: 2.447 s, System: 0.275 s]
  Range (min … max):    3.032 s …  4.243 s    10 runs
 
Summary
  'bin/godot.linuxbsd.opt.tools.64 /tmp/4/project.godot --quit' ran
    1.07 ± 0.17 times faster than 'bin/godot.linuxbsd.opt.debug.tools.64 /tmp/4/project.godot --quit'

With link-time optimization

❯ hyperfine -iw1 "bin/godot.linuxbsd.opt.tools.64 /tmp/4/project.godot --quit" "bin/godot.linuxbsd.opt.debug.tools.64 /tmp/4/project.godot --quit"
Benchmark #1: bin/godot.linuxbsd.opt.tools.64 /tmp/4/project.godot --quit
  Time (mean ± σ):      3.674 s ±  0.427 s    [User: 2.383 s, System: 0.300 s]
  Range (min … max):    2.989 s …  3.996 s    10 runs
 
Benchmark #2: bin/godot.linuxbsd.opt.debug.tools.64 /tmp/4/project.godot --quit
  Time (mean ± σ):      3.686 s ±  0.441 s    [User: 2.421 s, System: 0.292 s]
  Range (min … max):    3.090 s …  4.289 s    10 runs
 
Summary
  'bin/godot.linuxbsd.opt.tools.64 /tmp/4/project.godot --quit' ran
    1.00 ± 0.17 times faster than 'bin/godot.linuxbsd.opt.debug.tools.64 /tmp/4/project.godot --quit'

Editor binary size comparison (after running strip)

Without link-time optimization

• tools=yes target=release_debug: 107,600,752 bytes
• tools=yes target=release: 114,576,240 bytes

With link-time optimization

• tools=yes target=release_debug: 105,827,256 bytes
• tools=yes target=release: 108,252,144 bytes

[Calinou]

I've started to modify the Android Gradle code to make this work for the Android editor, but I haven't got it to work yet. Note that if you intend to test the Android buildsystem, you should cherry-pick #60358 on top to see a difference in terms of performance and binary size.

[m4gr3d]

I've started to modify the Android Gradle code to make this work for the Android editor, but I haven't got it to work yet. Note that if you intend to test the Android buildsystem, you should cherry-pick #60358 on top to see a difference in terms of performance and binary size.

@Calinou For Android, you also have to update the editor/build.gradle and lib/build.gradle to enable the release build target.

[Calinou]

Building for Android with tools=yes target=release now works, but the editor crashes on startup. This doesn't occur with target=release_debug (on this PR's branch).

[m4gr3d]

@Calinou Once you apply the feedback in the comments, you should be able to build and run the editor for release builds.

[Calinou]

@Calinou Once you apply the feedback in the comments, you should be able to build and run the editor for release builds.

I applied the feedback, but I unfortunately can't test this locally anymore as my Android development setup broke (likely after upgrading my system to Fedora 36).

[m4gr3d]

The updated Android build logic is mostly there, just some minor cleanups :)

[lawnjelly]

Just to comment that having a build called release with DEBUG_ENABLED set will surely be confusing? Maybe there could be another scons argument or different name for such a build?
e.g. release_debug_optimized or optimize=full something like that?

[Calinou]

Just to comment that having a build called release with DEBUG_ENABLED set will surely be confusing? Maybe there could be another scons argument or different name for such a build? e.g. release_debug_optimized or optimize=full something like that?

The goal of this PR is to remove usability roadblocks with regards to compiling Godot. Adding a new target would defeat this goal, so I'd rather do something like print a message when the build starts instead:

Note: Building with full release optimizations, but with debugging features still enabled as this is required for the editor.

[m4gr3d]

@Calinou @akien-mga Given the recent refactor of the build architecture, do we still see values in enabling this for the editor target?

[nyabinary]

Yeah, I'm also curious if there is any value in this at all after the refactor.

[Calinou]

@Calinou @akien-mga Given the recent refactor of the build architecture, do we still see values in enabling this for the editor target?

I think optimize=speed can be used with target=editor now, at least according to:

godot/SConstruct

Lines 548 to 549 in a8c805b

	if env["optimize"] == "speed":
	env.Append(CCFLAGS=["-O3"])

optimize=speed_trace is the default, and is equivalent to what was used before for target=release_debug (with or without tools).

Edit: optimize=speed indeed has an effect on editor builds. They're slightly larger (which confirms -O3 is used) and run minutely faster:

.rwxr-xr-x   81M hugo 17 Oct 23:33  godot.linuxbsd.template_debug.x86_64
.rwxr-xr-x   81M hugo 17 Oct 23:45  godot.linuxbsd.template_release.x86_64

~/Documents/Git/godotengine/godot/bin master ⇣
❯ hyperfine -iw1 -m20 "./godot.linuxbsd.editor.x86_64.optimize_speed --quit" "./godot.linuxbsd.editor.x86_64.optimize_speed_trace --quit"
Benchmark #1: ./godot.linuxbsd.editor.x86_64.optimize_speed --quit
  Time (mean ± σ):      2.839 s ±  0.089 s    [User: 1.510 s, System: 0.314 s]
  Range (min … max):    2.659 s …  3.032 s    20 runs
 
  Warning: Ignoring non-zero exit code.
 
Benchmark #2: ./godot.linuxbsd.editor.x86_64.optimize_speed_trace --quit
  Time (mean ± σ):      2.848 s ±  0.060 s    [User: 1.529 s, System: 0.299 s]
  Range (min … max):    2.659 s …  2.935 s    20 runs
 
  Warning: Ignoring non-zero exit code.
 
Summary
  './godot.linuxbsd.editor.x86_64.optimize_speed --quit' ran
    1.00 ± 0.04 times faster than './godot.linuxbsd.editor.x86_64.optimize_speed_trace --quit'

Closing, as this was made obsolete by #66242. A 3.x cherry-pick is welcome, but I don't have time to work on it.