First of all, it breaks rule #1 and #2 of optimization.
Rule 1: Don't do it.
Rule 2 (for experts only). Don't do it yet - that is, not until you have a perfectly clear and unoptimized solution.
-- Michael A. Jackson
Second of all, most of these optimizations are inconsequential. Sure you can show with a benchmark that one is faster than the other. That is because you are making n big by benchmarking, and n is usually small.
Applying these "performance improvements" to your code will have little to no impact.
Nobody is going to write
new HashSet<>(new ArrayList<>("one", "two", "three"))
That's what Arrays.asList() does.
It would be better to explain why one is faster than the other. Per your advice, the following code would be much slower, right? Try it, you'll be surprised.
new HashSet<>(list.size()).addAll(list);
Performance improvement suggestions should be accompanied with why one performs better than the other. In this case, it has everything to do with time spend in resizing the destination array of the HashSet. If you make it large enough to begin with, no resizing was needed. This is what happens with the constructor call.
If you really want to read up on Java performance improvements I can suggest the book Optimizing Java. It is a new book focused on newer Java versions, 6 and up to 12. Do note that this book is for an more advanced audience.
I can give you one simple Java performance optimization trick: Write small methods. There are a few reason for this:
JVM optimizes "hotspots". Small methods become "hot" more quickly.
JVM is better at (re)optimizing small methods.
Huge methods are disqualified for optimization.
So if you refactor your large method to 3 smaller methods, and 1 medium method. Then your 3 small methods might be optimized at some point, and make your code faster than.
So if you write Clean Code you not only make your code easier to understand, it can also grant you a performance boost.
Applying these "performance improvements" to your code will have little to no impact.
Again and yet again, I am reiterating here
Note: The JVM optimizes the code efficiently. So you do not need to optimize it for a general use cases. But if you want to drain the maximum performance out of JVM. Here we go.
Performance improvement suggestions should be accompanied with why one performs better than the other.
Yeah we can explain each one of them. Show the difference in the byte code and how JVM optimizes them and things like that (Maybe in future (when I have time))
new HashSet<>(list.size()).addAll(list);
I would be surprised, if they are not almost identical.
So if you refactor your large method to 3 smaller methods, and 1 medium method. Then your 3 small methods might be optimized at some point, and make your code faster than.
Create smaller methods, of course is in every clean code / perf optimization book.
But look out this when running on smaller devices, sometimes too many smaller methods will result in more inlining that will increase the memory pressure.
This is not good advice.
First of all, it breaks rule #1 and #2 of optimization.
Second of all, most of these optimizations are inconsequential. Sure you can show with a benchmark that one is faster than the other. That is because you are making
nbig by benchmarking, andnis usually small.Applying these "performance improvements" to your code will have little to no impact.
Nobody is going to write
That's what
Arrays.asList()does.It would be better to explain why one is faster than the other. Per your advice, the following code would be much slower, right? Try it, you'll be surprised.
Performance improvement suggestions should be accompanied with why one performs better than the other. In this case, it has everything to do with time spend in resizing the destination array of the
HashSet. If you make it large enough to begin with, no resizing was needed. This is what happens with the constructor call.If you really want to read up on Java performance improvements I can suggest the book Optimizing Java. It is a new book focused on newer Java versions, 6 and up to 12. Do note that this book is for an more advanced audience.
I can give you one simple Java performance optimization trick: Write small methods. There are a few reason for this:
So if you refactor your large method to 3 smaller methods, and 1 medium method. Then your 3 small methods might be optimized at some point, and make your code faster than.
So if you write Clean Code you not only make your code easier to understand, it can also grant you a performance boost.
Again and yet again, I am reiterating here
Note: The JVM optimizes the code efficiently. So you do not need to optimize it for a general use cases. But if you want to drain the maximum performance out of JVM. Here we go.Yeah we can explain each one of them. Show the difference in the byte code and how JVM optimizes them and things like that (Maybe in future (when I have time))
I would be surprised, if they are not almost identical.
Create
smallermethods, of course is in every clean code / perf optimization book.But look out this when running on smaller devices, sometimes too many smaller methods will result in more inlining that will increase the memory pressure.
Thanks for the
Optimizing Javabook