- Do you know what is quickest ever method to lookup string?
- Mmmm. Apparently hash table.
- Nope. Dude, its well known that binary search is quicker!
- ?!
Kind of similar to that was a conversation with one guy. (Cheers, Noel!) No doubt, to put it mildly, it sounds crazy: method with logarithmic asymptotic complexity outperform constant one. But it is only on first look. The devil is hiding in details, as always...
These days, there are more tools to play with benchmarks. No doubts, its really hard to do especially if they are micro. Let's cheers up an JMH. Really pretty good and easy to use framework for a writing the micro benchmarks for a JVM. To play with, I decided to come back to my old investigation about the Spring proxying, I did some time ago. But now, the list of targets are extended and tests are more representative.
First time I heard this phrase from the Thomas Jahn’s "Knockin’ on Heaven’s Door". In Russian it would sound like "reflected objects are closer than appeared". But that doesn't deform the sense, isn't? Exactly, namely distortion. That what appeared to be when I benchmarked the hash code calculation.
In past I spent some times on optimization of performance mostly JSE application. Recently I had a chance to play with enterprise Java.
Yes, they both are pretty same Java and life does not become heavier when you moving from Standard Edition land to Enterprise one. Except one note: the enterprise app supposed to be more complex so, is more "layered" application. Kind of "Shrek's onions":
- Ogres are like onions.
- They stink?
- Yes. No.
- Oh, they make you cry.
- No.
- Oh, you leave em out in the sun, they get all brown, start sproutin' little white hairs.
- No! Layers! Onions have layers. Ogres have layers. Onions have layers. You get it? We both have layers!
- Oh, you both have layers. Oh. You know, not everybody like onions.
Thats true, not everybody like ... layers. Especially when we talk about high performance, low-latency applications. Some people implied the Java to a heavy, multi-layered applications and blames it for so slow speed in comparison with C/C++. But, I think, that is unfairly...
Trimming string values a quite often task on the Web. I personally prefer avoid this in origin: just do not store redundant symbols. But you know, shit is happened... Sometimes data you have to use, came from side you can not control. Or even trimming is assumed by protocol.
String transformations are heavy by nature, but it is not a problem if operation is not time sensitive.
Not sure where and when I picked this habit, but usually I used construction:
if (null == value || "".equals(value.trim())) {
// data is empty or blank
}But recently I had been informed that this check is much slower compare to:
if (null == value || 0 == value.trim().length()) {
// data is empty or blank
}From my look point they both are heavy and should not be used in code that pretends to be a quick. It is even funny to hear about performance tricks in cases where it never appear to be meaningful. But I become interested how much it slower in fact. So, decided to make a quick test.