O'Reilly Japan -Java Performance Summary of Chapter 1 of this book
Chapter 1 Introduction --Qiita ← This article Chapter 2 Performance Testing Approach -Qiita ← Next article Chapter 3 Java Performance Toolbox -Qiita Chapter 4 How the JIT compiler works -Qiita Chapter 5 Basics of Garbage Collection -Qiita
This book describes two things: setting up the JVM and using a good standard API.
Ultimately, performance depends on the adequacy of your code. No matter how much you try to loop the code, the code that looks for a specific element can't beat the code that uses HashMap.
Some administrators still evaluate developers with the amount of code they write, A small amount of code is often more advantageous in terms of performance. This tendency seems to be strong especially in Java.
The more code you have to compile, the more time it takes for the JIT compiler to run the code faster. As the amount of objects that must be created and discarded increases, so does the amount of GC work. Keeping a lot of objects will extend the GC cycle. The more classes you load, the more time you have to start. As the size of the code executed increases, it may not fit in the cache.
Performance always deteriorates. Because functions will be added.
About 97% of the day should forget about trivial efficiency. Premature optimization is the root of all evil.
There is a famous word. You should write clean and straightforward code to make it easier to read, It should not be optimized without analysis (correction that complicates the structure at the cost of performance advantage). But avoiding code that is obviously a performance issue is another issue, and that's good.
For standalone applications that don't use external resources, the only performance bottleneck is that application. However, when using external resources, that becomes a bottleneck. In this book, we will explain Java performance assuming that the analysis is done not only for Java but for the whole.
Focus on frequent use cases.
Recommended Posts