Why Java is slow

Why Java is slow

Java was very slow in the Early Days (such as before JDK). Due to the addition of many optimization methods in subsequent versions, Java is getting faster and faster, so there are also a lot of arguments about Java and C/C ++. I want to talk about the factors that affect the Java program running speed in my own understanding.

1. GC recovery

As we all know, a major improvement of Java over C/C ++ is the GC mechanism, which can avoid common memory leaks in C/C ++. However, this is costly because the JVM manages the release of all memory allocations. When the memory is insufficient, it needs to be recycled. The entire heap is scanned every time the memory is recycled, then we need to move some memory data. The new generation is fine. If it is GC in the old age, it will cause the program to get stuck for a period of time, which is often unacceptable, it also greatly slowed down the running speed of the program. Although the GC algorithm is continuously improved, it can only be optimized but cannot be radical.

2. Explanatory Language

For cross-platform purposes, Java does not directly compile the code into machine commands, but bytecode. during runtime, the JVM needs to load these bytecode and then explain and execute them one by one. In this process, it takes time to load the bytecode, and then it takes time to explain the execution. To do the same thing, the compilation language can be directly compiled into machine code. During the runtime, the CPU directly executes these commands, while Java is compiled into bytecode, during the runtime, the JVM should translate bytecode into executable commands of the target machine, which adds an indirect layer and reduces the running speed.

3. resources consumed by JIT

JIT is an improved function of later Java versions. It can instantly compile commonly executed methods or statement blocks into machine code, which can indeed speed up the operation. However, this kind of compilation happens instantly, and it will compete with the program itself to run resources, which will slow down the program running speed.

4. stack-based instruction sets

The compilation language mostly uses the instruction set based on the register of the Target Platform, which can make full use of the Register's high speed. Java uses a stack-based instruction set instead of a register bound to a target platform for portability. Frequent stack memory access will lead to a relatively slow speed, and the number of commands generated by compiling the same statement is usually more than the register instruction set.

5. A large amount of heap memory

The creation of objects in Java is managed by JVM, which can avoid cross-border or NULL pointer access and other common problems in C/C ++. Therefore, most objects are created on the stack instead of the stack. The creation and maintenance costs are usually higher.

6. AOT Technology

When the AOT technology is installed on the target platform with bytecode, it is first compiled into the execution file of the target platform, so that the target platform can directly run the executable file, the speed can reach the compilation level. However, this will lead to the loss of the Dynamic Loading Function of Java, and all bytecode will be compiled into the execution file, whether or not it is used at runtime, in addition, the executable file generated by the file is larger than the bytecode.

In general, Java has made great progress in development efficiency due to its cross-platform and memory management features. However, there are also advantages and disadvantages in everything, and the decrease in running efficiency comes along with it. Only by fully understanding these advantages and disadvantages can we select the appropriate technology at the right time to maximize the efficiency.

(End)