Why are Debug & Release assemblies for .Net, but not for Java?

In .Net, you can specifically compile your projects in the "Debug" or "Release" settings, Release has more optimizations. I know this is considered unnecessary in Java because jitter does these optimizations. What is the reason for the difference? (which means why pre-compiling "jitter" is necessary / useful)

Why is this considered necessary in .Net / CLR, but not in Java / JDK?

+7
source share
4 answers

Java compilers used to have the -O flag to enable (source code) compilation optimization. With JDK 1.2, the -O flag had no effect, and I believe that the flag was removed with JDK 1.4. As Java runtime improves, it is probably more sensible to delegate JRE optimization because the source code compiler is not aware of the hardware that will ultimately execute the code.

Articles such as this and the csc / optimize flag documentation show that optimization has very little impact (if at all?) On the actual generation of CLR code. However, the / optimize flag sets a flag in the compiled assembly, which controls the level of optimization allowed to be applied at runtime. I did not try, but I read that the optimized runtime code is not necessarily debugged, although debugging information is enabled (the / optimize and / debug flags can be enabled or disabled independently for the C # compiler).

Ξ™ I really don’t see any reason to control the level of optimization of runtime at compile time. Java runtime has several detailed parameters to control performance and execution optimization, but they must be determined when starting the JRE, and not at compile time.

+4
source

Sun javac The compiler has a concept for debugging information that can (optionally) be omitted from the compiled class.

Check the documentation and check the -g flags:

 -g Generate all debugging information, including local variables. By default, only line number and source file information is generated. -g:none Do not generate any debugging information. -g:{keyword list} Generate only some kinds of debugging information, specified by a comma separated list of keywords. Valid keywords are: source Source file debugging information lines Line number debugging information vars Local variable debugging information 

They may not be as extensive as the bytecode optimization that .NET compilers can do (which I am not familiar with, sorry), but I think that they exist in theory for performance reasons (smaller class files, etc.) .

In practice, I strongly suspect that they will not make much difference to runtime performance on modern hardware + JVMs, but they are.

+4
source

I think they can be easily entered into Java. Basically, the Debug assembly: enables debugging symbols and disables optimization. Release is the other way around. Debugging and release targets are generated by Visual Studio and are optional. You can write your MSBuild script without VS. This way you can create a build script for Java with debugging and release goals.

+3
source

http://blogs.msdn.com/b/ericlippert/archive/2009/06/11/what-does-the-optimize-switch-do.aspx has a nice list of optimizations that are performed when the optimization switch is on (it's on for release, shutdown for debugging).

The Java compiler can also perform any of these actions, and in any case, it can perform some of them. They are mostly small wins.

0
source

All Articles