I decided to compare the performance of different collection iteration options. In particular:
📍 for loop
📍enhanced for loop
📍for loop with an Iterator
📍stream
Details🧵👇
To test it, I have implemented 4 Benchmark methods, each iterating through list of positive integers and checking them for equality to -1. And at the end of the method, it returns 0 since non was found. In short: Just iterating through the entire collection.
Results:
✅for (Integer i : list) 781 ns/op
✅for (int i = 0; i < listSize; i++) 785 ns/op
✅while (iterator.hasNext()) 788 ns/op
❌list.stream() ns/op 3256 ns/op 4x slower 😱👀
The result shows that loops perform the same, but the stream is 4 times slower than loops.I think it's mainly slower because of the overhead added by lambda instantiations.
Conclusion: If your only goal is performance, use loops, but in all other cases, use streams for readability. And let's hope that newer versions of Java can improve stream performance.
⚠️Top 5 Trending Java GitHub repositories February 2023⚠️
(Android excluded)
🧵👇
1️⃣ OpenAI-Java - Java libraries for using OpenAI's GPT-3 api.
Includes:
api - request/response POJOs for the GPT-3 APIs
client - retrofit client for the GPT-3 endpoints
service - service class that creates and calls the client
2️⃣Karate - is the only open-source tool to combine API test-automation, mocks, performance-testing and even UI automation into a single, unified framework.
To show the difference in performance between primitive and wrapper objects I have created a benchmark which just creates an array of "int" and "Integer" and fills them with an index. Sizes of array: "10", "100", "1000", "10000"
Based on the "Scout Rule", which is "always leave the campground cleaner than you found it", the Scout Rule in programming is simply "always leave the code cleaner than you found it".
This was introduced in the first chapter of the book Clean Code by Bob Martin.
The rule suggests that developers should perform 'optimistic refactoring', which means to endeavour to improve the overall quality of the code when you work on it if you see a mistake, attempt to fix it or clean it up.
This law suggests that groups will give far more time and attention to trivial or cosmetic issues rather than serious and substantial ones.
The common fictional example used is that of a committee approving plans for nuclear power plant, who spend the majority of their time discussing the structure of the bike shed, rather than the far more important design for the power plant itself.
It can be difficult to give valuable input on discussions about very large, complex topics without a high degree of subject matter expertise or preparation. However, people want to be seen to be contributing valuable input.
Don't use "+" for string concatenation. Use StringBuilder or StringBuffer instead.
I have created a benchmark to compare the speed of StringBuilder, StringBuffer and "+" concatenation for 2, 3, 5, 10, 50, and 100 strings.
Details in 🧵👇
The scenario is simple:
s/sb = ""/new StringBuffer/Builder();
for (int i = 0; i < size; i++) {
s+=i;/sb.append(i);
}
return sb.toString();
size = 2, 3, 5, 10, 50, and 100
Size hundred produced super strange result, which I can't explain yet. 😕
#Java performance Tip: `parallelStream()` is way slower than regular `stream()` on small amount of data. I have created a simple benchmark and run it on my 8-CPU laptop. The difference is 160x for some cases. 😲
Details 🧵 👇
👷The setup is to run the same code for streams of 10, 1000, 10_000, 100_000, and 1000_000 items long in standard and parallel modes: list.stream()
.filter(i -> i == -1)
.findAny()
.orElse(0);