5 ms·

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

hyperpape 9y ago
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.
vvanders 9y ago
Also for(Foo x : y) will allocate iterators on some JVM implementations which will nail you on the GC.
- _old_dude_ 9y ago
  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" !
  - jnordwick 9y ago
    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.
    - _old_dude_ 9y ago
      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.
- hyperpape 9y ago
  Is this really a consideration outside of cases where someone is tuning their system so that it never does garbage collection?
  - vvanders 9y ago
    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.
    - _old_dude_ 9y ago
      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.
- reader_1000 9y ago
  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-arraylistiterator.html http://psy-lob-saw.blogspot.com.tr/2014/12/the-escape-of-arr...
sorokod 9y ago
If you are not using JMH (http://openjdk.java.net/projects/code-tools/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.

hyperpape 9y ago

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.

vvanders 9y ago

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

_old_dude_ 9y ago
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" !
- jnordwick 9y ago
  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.
  - _old_dude_ 9y ago
    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.
hyperpape 9y ago
Is this really a consideration outside of cases where someone is tuning their system so that it never does garbage collection?
- vvanders 9y ago
  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.
  - _old_dude_ 9y ago
    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.
reader_1000 9y ago
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-arraylistiterator.html http://psy-lob-saw.blogspot.com.tr/2014/12/the-escape-of-arr...

sorokod 9y ago

If you are not using JMH (http://openjdk.java.net/projects/code-tools/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.