[ETCM-736] Enable compiler optimizations in Prod

[jb-lunatech]

Description

Enable compiler inlining optimizations as described here https://www.lightbend.com/blog/scala-inliner-optimizer

TL;DR
Don’t enable the optimizer during development: it breaks incremental compilation, and it makes the compiler slower. Only enable it for testing, on CI, and to build releases.
Enable method-local optimizations with -opt:l:method. This option is safe for binary compatibility, but typically doesn’t improve performance on its own.
Enable inlining in addition to method-local optimizations with -opt:l:inline and -opt-inline-from:[PATTERN]
Don’t inline from your dependencies when publishing a library, it breaks binary compatibility. Use -opt-inline-from:my.package.** to only inline from packages within your library.
When compiling an application with global inlining (-opt-inline-from:**), ensure that the run-time classpath is exactly the same as the compile-time classpath.
The @inline annotation only has an effect if the inliner is enabled. It tells the inliner to always try to inline the annotated method or callsite.
Without the @inline annotation, the inliner generally inlines higher-order methods and forwarder methods. The main goal is to eliminate megamorphic callsites due to functions passed as argument, and to eliminate value boxing. Other optimizations are delegated to the JVM.

See also documentation and options renaming ticket

Proposed Solution

• Enable the optimizations for production only (see option -DmantisDev and flag MANTISDEV)
• Restrict the optimization to the project since the main goal is to inline logging calls

Do we want to set it for tests and integration tests as well? Switching off dev mode might be a more clear way to achieve this... We agreed to keep it simple : production mode has optimization, dev mode does not, hence to test with inlinine toggle to production mode

Important Changes Introduced

Reminder

To enable dev mode, -DmantisDev=true or MANTIS_DEV=true

Ensuring that compile-time and run-time classpaths are the same

This section is kept for documentation purposes, it has been decided not to enable inline globally

Difference between the classpaths (on my machine, emptied caches)

Compile-time	Run-time	Issue
(sbt export compile:fullClasspath)	(sbt export runtime:fullClasspath)
scala-collection-compat_2.13-2.3.2.jar	scala-collection-compat_2.13-2.1.6.jar	See below
Scala XML	ø	Not an issue
Scapegoat plugin	ø	Not an issue

ScalaPb library is the only library depending on scala-collection-compat (latest 2.4.3) and it also imposes the version of scala-collection-compat to be used. Currently the project depends on ScalaPb 0.10.9 which imposes scala-collection-compat_2.13-2.1.6 (https://github.com/scalapb/ScalaPB/blob/v0.10.9/project/Dependencies.scala#L13) whereas the latest is 0.11.1 imposing scala-collection-compat-2.4.3.
Note : Monix also defines a dependency to scala-collection-compat
via Def.settings https://github.com/monix/monix/blob/cb4823427db8b1f8fdf990bf27b307b396892a76/build.sbt#L89, this potentially explains the discrepancy between the classpaths.

Potential solutions

• align the version between the compile-time and run-time classpaths, or
• exclude optimizations fromt the classpath as suggested from libraries (-opt-inline-from:my.package.**)

Testing

• Inlining changes logs can be seen with the scalac "-Yopt-log-inline", "_" option.
• Compare compile:fullClasspath vs runtime:fullClasspath
• Run Mantis

[dzajkowski]

wouldn't it make sense to limit this scope?

[dzajkowski]

let's get it in, I'll build a logging wrapper on top of this change. btw would it be possible to enable this by default on CI?

[jonringer]

btw would it be possible to enable this by default on CI?

We don't set any env variables, so I believe they should be getting applied