Hacker News Reader

Comment by kasey_junk | Hacker News Reader

Be careful with 2) because of inlining. Can’t count the number of times I wrote benchmarks that got completely inlined away.

View on HN

If you are not using JMH (http://openjdk.java.net/projects/code-tools/jmh/) for micro-benchmarking, you are very likely doing it wrong. Inlining is just a tip of the gotchas iceberg.

Agreed. The vast majority of the time you should be using JMH for microbenchmarks on the JVM. If you read the samples and understand them and apply those ideas, it takes care of the inlining problem.

Also for(Foo x : y) will allocate iterators on some JVM implementations which will nail you on the GC.

It's not on some JVM implementations, to be able to remove the Iterator creation, the VM requires the call to y.iterator() to be either monomorphic or bimorphic.

Hence the advice "Keep Things Monomorphic or Bimorphic" !

Even if it inline the iteration creation and calls, then hoist and remove the allocation, you're likely to see suboptimal instructions.

On hot paths, I often find it better to just avoid iterators in the first place than trying to clean up the mess later.

yes, the Iterator protocol of Java is sub-optimal - hasNext() has to be called twice so you hope the VM will kick the common sub expression elimination which i have found works well only if you do not do any side effect in hasNext. - and most of the Iterator are fail fast so the code has to check that the modCount of the collection has not changed.

but from my own experience, you usually do not have to optimize that far, removing that 'synchronized' block, is far more common.

Is this really a consideration outside of cases where someone is tuning their system so that it never does garbage collection?

Very much so, I see this all the time in production Android code. Someone throws in an iterator like this in an onDraw() and now your super-fast code is hitting a GC pause every hundred ms or so.

Android do not use a real JIT (no inlining) so it's mostly an AOT, and removing the Iterator allocation require to know the real class of the iterator.

I'm not a pro of Android, so i wonder if the AOT system of Android (ART) has an option to provide a profile like you can do with gcc. It seems a better idea than to have to rewrite all the codes, third party codes included.

Escape analysis should handle this [1], but I don't know if it does all the time. Reliably profiling this is hard, I guess.

http://psy-lob-saw.blogspot.com.tr/2014/12/the-escape-of-arr...

Reply on news.ycombinator.com