Any fool can write code that a computer can understand. Good programmers write code that humans can understand. - Martin Fowler
But the itch to ...
For further actions, you may consider blocking this person and/or reporting abuse
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
n
big by benchmarking, andn
is 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
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.
Thanks for the
Optimizing Java
bookSome of the things are irrelevant because recent JVM can optimize them. I'm taking about StringBuffer and perhaps some stuff involving inlining of your code. However the 1000 repetition limit is not enough to experience that.
Especially things like #6. I'm sure the JVM would inline those calculations if the intermediate variables aren't used anywhere else.
The #6 is just an example.
I completely agree JVM optimizes in a lot of ways.
StringBuffer is way more efficient than normal String concatenation.
And this is on JDK 12.
For some reason your JDK decided out to replace str concat with stringbuilder.
Look here for more information:
dzone.com/articles/jdk-9jep-280-st...
Some of these promote speed over legibility, which I think is a dangerous mindset. I try to make intentions clear when writing code, even if it isn't the fastest. If it appears to be an issue, I can then profile the code and research effective changes. Without realistic use cases, I don't think benchmarks are of any value...that's part of why we have so many JS performance issues today; the engines were designed to score well on benchmark tests that have little to do with real-world usage of the engine.
That is a vague statement. Have you read the first quote? I think that clearly specifies clean code is important.
This was exactly the point.
The problem with JS performance are not due to engine. It is often because we do not know how this engine works. Irrespective of engine, if you are writing poly/mega-morphic code the performance will be slow. We have to understand that when writing. The engines are tuned for real life cases too but it is not possible to cover them fully.
The "use StringBuilder" is much too general. Maybe have a look at the following talk by Heinz Kabutz:
youtu.be/z3yu1kjtcok
He talks an hours about Java Strings and performance.
For performance surprises, the following talk is also a recommendation: youtu.be/fN3MtD-lNHc
Its conclusion, which I support, is: Performance is full of surprises, write clean code. If necessary focus on the hot spots.
Great article. Thanks for sharing :)
I would've added as a bonus point the book:"Clean Code".
It helped me to learn best practices and enhance my code.
I couldnt agree more π
Hi @hussein cheayto, can you please tell the author name or mention Amazon link for the book "clean code". Thank you.
Here is the amazon link - amzn.to/2Y3wpb6
Thanks for the article. Definitely gonna use all these in solving competitive programming questions.