How do I write a correct micro-benchmark in Java?












765














How do you write (and run) a correct micro-benchmark in Java?



I'm looking here for code samples and comments illustrating various things to think about.



Example: Should the benchmark measure time/iteration or iterations/time, and why?



Related: Is stopwatch benchmarking acceptable?










share|improve this question
























  • See [this question][1] from a few minutes ago for some related info. edit: sorry, this is not supposed to be a answer. I should've posted as a comment. [1]: stackoverflow.com/questions/503877/…
    – Tiago
    Feb 1 '11 at 14:07










  • It was after planning to refer the poster of that question to a question like this that I noted that this question didn't exists. So here it is, hopefully it will assemble some good tips over time.
    – John Nilsson
    Feb 1 '11 at 14:07






  • 4




    Java 9 might provide some features for micro-benchmarking: openjdk.java.net/jeps/230
    – Raedwald
    May 13 '15 at 9:33






  • 1




    @Raedwald I think that that JEP aims to add some micro benchmark to the JDK code, but I don't think that jmh will be included in the JDK...
    – assylias
    Dec 1 '15 at 16:11










  • Likely duplicate: How do I time a method's execution in Java?
    – Basil Bourque
    Jul 1 '16 at 22:48
















765














How do you write (and run) a correct micro-benchmark in Java?



I'm looking here for code samples and comments illustrating various things to think about.



Example: Should the benchmark measure time/iteration or iterations/time, and why?



Related: Is stopwatch benchmarking acceptable?










share|improve this question
























  • See [this question][1] from a few minutes ago for some related info. edit: sorry, this is not supposed to be a answer. I should've posted as a comment. [1]: stackoverflow.com/questions/503877/…
    – Tiago
    Feb 1 '11 at 14:07










  • It was after planning to refer the poster of that question to a question like this that I noted that this question didn't exists. So here it is, hopefully it will assemble some good tips over time.
    – John Nilsson
    Feb 1 '11 at 14:07






  • 4




    Java 9 might provide some features for micro-benchmarking: openjdk.java.net/jeps/230
    – Raedwald
    May 13 '15 at 9:33






  • 1




    @Raedwald I think that that JEP aims to add some micro benchmark to the JDK code, but I don't think that jmh will be included in the JDK...
    – assylias
    Dec 1 '15 at 16:11










  • Likely duplicate: How do I time a method's execution in Java?
    – Basil Bourque
    Jul 1 '16 at 22:48














765












765








765


577





How do you write (and run) a correct micro-benchmark in Java?



I'm looking here for code samples and comments illustrating various things to think about.



Example: Should the benchmark measure time/iteration or iterations/time, and why?



Related: Is stopwatch benchmarking acceptable?










share|improve this question















How do you write (and run) a correct micro-benchmark in Java?



I'm looking here for code samples and comments illustrating various things to think about.



Example: Should the benchmark measure time/iteration or iterations/time, and why?



Related: Is stopwatch benchmarking acceptable?







java jvm benchmarking jvm-hotspot microbenchmark






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited May 23 '17 at 12:26









Community

11




11










asked Feb 2 '09 at 17:39









John NilssonJohn Nilsson

9,79282639




9,79282639












  • See [this question][1] from a few minutes ago for some related info. edit: sorry, this is not supposed to be a answer. I should've posted as a comment. [1]: stackoverflow.com/questions/503877/…
    – Tiago
    Feb 1 '11 at 14:07










  • It was after planning to refer the poster of that question to a question like this that I noted that this question didn't exists. So here it is, hopefully it will assemble some good tips over time.
    – John Nilsson
    Feb 1 '11 at 14:07






  • 4




    Java 9 might provide some features for micro-benchmarking: openjdk.java.net/jeps/230
    – Raedwald
    May 13 '15 at 9:33






  • 1




    @Raedwald I think that that JEP aims to add some micro benchmark to the JDK code, but I don't think that jmh will be included in the JDK...
    – assylias
    Dec 1 '15 at 16:11










  • Likely duplicate: How do I time a method's execution in Java?
    – Basil Bourque
    Jul 1 '16 at 22:48


















  • See [this question][1] from a few minutes ago for some related info. edit: sorry, this is not supposed to be a answer. I should've posted as a comment. [1]: stackoverflow.com/questions/503877/…
    – Tiago
    Feb 1 '11 at 14:07










  • It was after planning to refer the poster of that question to a question like this that I noted that this question didn't exists. So here it is, hopefully it will assemble some good tips over time.
    – John Nilsson
    Feb 1 '11 at 14:07






  • 4




    Java 9 might provide some features for micro-benchmarking: openjdk.java.net/jeps/230
    – Raedwald
    May 13 '15 at 9:33






  • 1




    @Raedwald I think that that JEP aims to add some micro benchmark to the JDK code, but I don't think that jmh will be included in the JDK...
    – assylias
    Dec 1 '15 at 16:11










  • Likely duplicate: How do I time a method's execution in Java?
    – Basil Bourque
    Jul 1 '16 at 22:48
















See [this question][1] from a few minutes ago for some related info. edit: sorry, this is not supposed to be a answer. I should've posted as a comment. [1]: stackoverflow.com/questions/503877/…
– Tiago
Feb 1 '11 at 14:07




See [this question][1] from a few minutes ago for some related info. edit: sorry, this is not supposed to be a answer. I should've posted as a comment. [1]: stackoverflow.com/questions/503877/…
– Tiago
Feb 1 '11 at 14:07












It was after planning to refer the poster of that question to a question like this that I noted that this question didn't exists. So here it is, hopefully it will assemble some good tips over time.
– John Nilsson
Feb 1 '11 at 14:07




It was after planning to refer the poster of that question to a question like this that I noted that this question didn't exists. So here it is, hopefully it will assemble some good tips over time.
– John Nilsson
Feb 1 '11 at 14:07




4




4




Java 9 might provide some features for micro-benchmarking: openjdk.java.net/jeps/230
– Raedwald
May 13 '15 at 9:33




Java 9 might provide some features for micro-benchmarking: openjdk.java.net/jeps/230
– Raedwald
May 13 '15 at 9:33




1




1




@Raedwald I think that that JEP aims to add some micro benchmark to the JDK code, but I don't think that jmh will be included in the JDK...
– assylias
Dec 1 '15 at 16:11




@Raedwald I think that that JEP aims to add some micro benchmark to the JDK code, but I don't think that jmh will be included in the JDK...
– assylias
Dec 1 '15 at 16:11












Likely duplicate: How do I time a method's execution in Java?
– Basil Bourque
Jul 1 '16 at 22:48




Likely duplicate: How do I time a method's execution in Java?
– Basil Bourque
Jul 1 '16 at 22:48












11 Answers
11






active

oldest

votes


















708














Tips about writing micro benchmarks from the creators of Java HotSpot:



Rule 0: Read a reputable paper on JVMs and micro-benchmarking. A good one is Brian Goetz, 2005. Do not expect too much from micro-benchmarks; they measure only a limited range of JVM performance characteristics.



Rule 1: Always include a warmup phase which runs your test kernel all the way through, enough to trigger all initializations and compilations before timing phase(s). (Fewer iterations is OK on the warmup phase. The rule of thumb is several tens of thousands of inner loop iterations.)



Rule 2: Always run with -XX:+PrintCompilation, -verbose:gc, etc., so you can verify that the compiler and other parts of the JVM are not doing unexpected work during your timing phase.



Rule 2.1: Print messages at the beginning and end of timing and warmup phases, so you can verify that there is no output from Rule 2 during the timing phase.



Rule 3: Be aware of the difference between -client and -server, and OSR and regular compilations. The -XX:+PrintCompilation flag reports OSR compilations with an at-sign to denote the non-initial entry point, for example: Trouble$1::run @ 2 (41 bytes). Prefer server to client, and regular to OSR, if you are after best performance.



Rule 4: Be aware of initialization effects. Do not print for the first time during your timing phase, since printing loads and initializes classes. Do not load new classes outside of the warmup phase (or final reporting phase), unless you are testing class loading specifically (and in that case load only the test classes). Rule 2 is your first line of defense against such effects.



Rule 5: Be aware of deoptimization and recompilation effects. Do not take any code path for the first time in the timing phase, because the compiler may junk and recompile the code, based on an earlier optimistic assumption that the path was not going to be used at all. Rule 2 is your first line of defense against such effects.



Rule 6: Use appropriate tools to read the compiler's mind, and expect to be surprised by the code it produces. Inspect the code yourself before forming theories about what makes something faster or slower.



Rule 7: Reduce noise in your measurements. Run your benchmark on a quiet machine, and run it several times, discarding outliers. Use -Xbatch to serialize the compiler with the application, and consider setting -XX:CICompilerCount=1 to prevent the compiler from running in parallel with itself. Try your best to reduce GC overhead, set Xmx(large enough) equals Xms and use UseEpsilonGC if it is available.



Rule 8: Use a library for your benchmark as it is probably more efficient and was already debugged for this sole purpose. Such as JMH, Caliper or Bill and Paul's Excellent UCSD Benchmarks for Java.






share|improve this answer



















  • 5




    This was also an interesting article: ibm.com/developerworks/java/library/j-jtp12214
    – John Nilsson
    Jul 10 '10 at 22:29






  • 123




    Also, never use System.currentTimeMillis() unless you are OK with + or - 15 ms accuracy, which is typical on most OS + JVM combinations. Use System.nanoTime() instead.
    – Scott Carey
    Apr 22 '11 at 18:43








  • 5




    Some paper from javaOne: azulsystems.com/events/javaone_2009/session/…
    – bestsss
    Jun 5 '11 at 12:29






  • 86




    It should be noted that System.nanoTime() is not guaranteed to be more accurate than System.currentTimeMillis(). It is only guaranteed to be at least as accurate. It usually is substantially more accurate, however.
    – Gravity
    Jul 27 '11 at 8:00








  • 36




    The main reason why one must use System.nanoTime() instead of System.currentTimeMillis() is that the former is guaranteed to be monotonically increasing. Subtracting the values returned two currentTimeMillis invocations can actually give negative results, possibly because the system time was adjusted by some NTP daemon.
    – Waldheinz
    Mar 16 '15 at 10:51



















223














I know this question has been marked as answered but I wanted to mention two libraries that enable us to write micro benchmarks



Caliper from Google



Getting started tutorials




  1. http://codingjunkie.net/micro-benchmarking-with-caliper/

  2. http://vertexlabs.co.uk/blog/caliper


JMH from OpenJDK



Getting started tutorials




  1. Avoiding Benchmarking Pitfalls on the JVM

  2. http://nitschinger.at/Using-JMH-for-Java-Microbenchmarking

  3. http://java-performance.info/jmh/






share|improve this answer



















  • 34




    +1 it could have been added as Rule 8 of the accepted answer: Rule 8: because so many things can go wrong, you should probably use an existing library rather than trying to do it yourself!
    – assylias
    Dec 6 '12 at 23:58






  • 7




    @Pangea jmh is probably superior to Caliper nowadays, See also: groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/…
    – assylias
    Dec 3 '15 at 9:49



















78














Important things for Java benchmarks are:




  • Warm up the JIT first by running the code several times before timing it

  • Make sure you run it for long enough to be able to measure the results in seconds or (better) tens of seconds

  • While you can't call System.gc() between iterations, it's a good idea to run it between tests, so that each test will hopefully get a "clean" memory space to work with. (Yes, gc() is more of a hint than a guarantee, but it's very likely that it really will garbage collect in my experience.)

  • I like to display iterations and time, and a score of time/iteration which can be scaled such that the "best" algorithm gets a score of 1.0 and others are scored in a relative fashion. This means you can run all algorithms for a longish time, varying both number of iterations and time, but still getting comparable results.


I'm just in the process of blogging about the design of a benchmarking framework in .NET. I've got a couple of earlier posts which may be able to give you some ideas - not everything will be appropriate, of course, but some of it may be.






share|improve this answer



















  • 3




    Minor nitpick: IMO "so that each test gets" should be "so that each test might get" since the former gives the impression that calling gc always frees up unused memory.
    – Sanjay T. Sharma
    Apr 20 '13 at 6:52












  • @SanjayT.Sharma: Well, the intention is that it actually does. While it's not strictly guaranteed, it's actually a pretty strong hint. Will edit to be clearer.
    – Jon Skeet
    Apr 20 '13 at 8:02






  • 1




    I don't agree with calling System.gc(). It is a hint, that's all. Not even "it will hopefully do something". You should never ever call it. This is programming, not art.
    – gyorgyabraham
    Jun 14 '13 at 10:38






  • 13




    @gyabraham: Yes, it's a hint - but it's one which I've observed to usually be taken. So if you don't like using System.gc(), how do you propose to minimize garbage collection in one test due to objects created in previous tests? I'm pragmatic, not dogmatic.
    – Jon Skeet
    Jun 14 '13 at 10:58






  • 9




    @gyabraham: I don't know what you mean by "great fallback". Can you elaborate, and again - do you have a proposal to give better results? I did explicitly say that it's not a guarantee...
    – Jon Skeet
    Jun 14 '13 at 17:44



















43














jmh is a recent addition to OpenJDK and has been written by some performance engineers from Oracle. Certainly worth having a look.




The jmh is a Java harness for building, running, and analysing nano/micro/macro benchmarks written in Java and other languages targetting the JVM.




Very interesting pieces of information buried in the sample tests comments.



See also:




  • Avoiding Benchmarking Pitfalls on the JVM


  • Discussion on the main strengths of jmh.






share|improve this answer



















  • 1




    See also this blog post: psy-lob-saw.blogspot.com/2013/04/… for details on getting started with JMH.
    – Nitsan Wakart
    May 2 '13 at 15:41












  • FYI, JEP 230: Microbenchmark Suite is an OpenJDK proposal based on this Java Microbenchmark Harness (JMH) project. Did not make the cut for Java 9 but may be added later.
    – Basil Bourque
    Jul 1 '16 at 23:03





















17















Should the benchmark measure time/iteration or iterations/time, and why?




It depends on what you are trying to test. If you are interested in latency, use time/iteration and if you are interested in throughput use iterations/time.






share|improve this answer





























    14














    Make sure you somehow use results which are computed in benchmarked code. Otherwise your code can be optimized away.






    share|improve this answer





























      12














      If you are trying to compare two algorithms, do at least two benchmarks on each, alternating the order. i.e.:



      for(i=1..n)
      alg1();
      for(i=1..n)
      alg2();
      for(i=1..n)
      alg2();
      for(i=1..n)
      alg1();


      I have found some noticeable differences (5-10% sometimes) in the runtime of the same algorithm in different passes..



      Also, make sure that n is very large, so that the runtime of each loop is at the very least 10 seconds or so. The more iterations, the more significant figures in your benchmark time and the more reliable that data is.






      share|improve this answer

















      • 5




        Naturally changing the order influences the runtime. JVM-optimizations and caching-effects are going to work here. Better is to 'warm up' the JVM-optimization, mak multiple runs and benchmark every test in a different JVM.
        – Mnementh
        Feb 2 '09 at 18:04



















      12














      There are many possible pitfalls for writing micro-benchmarks in Java.



      First: You have to calculate with all sorts of events that take time more or less random: Garbage collection, caching effects (of OS for files and of CPU for memory), IO etc.



      Second: You cannot trust the accuracy of the measured times for very short intervals.



      Third: The JVM optimizes your code while executing. So different runs in the same JVM-instance will become faster and faster.



      My recommendations: Make your benchmark run some seconds, that is more reliable than a runtime over milliseconds. Warm up the JVM (means running the benchmark at least once without measuring, that the JVM can run optimizations). And run your benchmark multiple times (maybe 5 times) and take the median-value. Run every micro-benchmark in a new JVM-instance (call for every benchmark new Java) otherwise optimization effects of the JVM can influence later running tests. Don't execute things, that aren't executed in the warmup-phase (as this could trigger class-load and recompilation).






      share|improve this answer































        7














        It should also be noted that it might also be important to analyze the results of the micro benchmark when comparing different implementations. Therefore a significance test should be made.



        This is because implementation A might be faster during most of the runs of the benchmark than implementation B. But A might also have a higher spread, so the measured performance benefit of A won't be of any significance when compared with B.



        So it is also important to write and run a micro benchmark correctly, but also to analyze it correctly.






        share|improve this answer





























          6














          http://opt.sourceforge.net/ Java Micro Benchmark - control tasks required to determine the comparative performance characteristics of the computer system on different platforms. Can be used to guide optimization decisions and to compare different Java implementations.






          share|improve this answer

















          • 1




            Seems to just benchmark the JVM + hardware, not an arbitrary piece of Java code.
            – Stefan L
            Feb 29 '12 at 22:05



















          5














          To add to the other excellent advice, I'd also be mindful of the following:



          For some CPUs (e.g. Intel Core i5 range with TurboBoost), the temperature (and number of cores currently being used, as well as thier utilisation percent) affects the clock speed. Since CPUs are dynamically clocked, this can affect your results. For example, if you have a single-threaded application, the maximum clock speed (with TurboBoost) is higher than for an application using all cores. This can therefore interfere with comparisons of single and multi-threaded performance on some systems. Bear in mind that the temperature and volatages also affect how long Turbo frequency is maintained.



          Perhaps a more fundamentally important aspect that you have direct control over: make sure you're measuring the right thing! For example, if you're using System.nanoTime() to benchmark a particular bit of code, put the calls to the assignment in places that make sense to avoid measuring things which you aren't interested in. For example, don't do:



          long startTime = System.nanoTime();
          //code here...
          System.out.println("Code took "+(System.nanoTime()-startTime)+"nano seconds");


          Problem is you're not immediately getting the end time when the code has finished. Instead, try the following:



          final long endTime, startTime = System.nanoTime();
          //code here...
          endTime = System.nanoTime();
          System.out.println("Code took "+(endTime-startTime)+"nano seconds");





          share|improve this answer




















            protected by Will Feb 1 '11 at 14:07



            Thank you for your interest in this question.
            Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



            Would you like to answer one of these unanswered questions instead?














            11 Answers
            11






            active

            oldest

            votes








            11 Answers
            11






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            708














            Tips about writing micro benchmarks from the creators of Java HotSpot:



            Rule 0: Read a reputable paper on JVMs and micro-benchmarking. A good one is Brian Goetz, 2005. Do not expect too much from micro-benchmarks; they measure only a limited range of JVM performance characteristics.



            Rule 1: Always include a warmup phase which runs your test kernel all the way through, enough to trigger all initializations and compilations before timing phase(s). (Fewer iterations is OK on the warmup phase. The rule of thumb is several tens of thousands of inner loop iterations.)



            Rule 2: Always run with -XX:+PrintCompilation, -verbose:gc, etc., so you can verify that the compiler and other parts of the JVM are not doing unexpected work during your timing phase.



            Rule 2.1: Print messages at the beginning and end of timing and warmup phases, so you can verify that there is no output from Rule 2 during the timing phase.



            Rule 3: Be aware of the difference between -client and -server, and OSR and regular compilations. The -XX:+PrintCompilation flag reports OSR compilations with an at-sign to denote the non-initial entry point, for example: Trouble$1::run @ 2 (41 bytes). Prefer server to client, and regular to OSR, if you are after best performance.



            Rule 4: Be aware of initialization effects. Do not print for the first time during your timing phase, since printing loads and initializes classes. Do not load new classes outside of the warmup phase (or final reporting phase), unless you are testing class loading specifically (and in that case load only the test classes). Rule 2 is your first line of defense against such effects.



            Rule 5: Be aware of deoptimization and recompilation effects. Do not take any code path for the first time in the timing phase, because the compiler may junk and recompile the code, based on an earlier optimistic assumption that the path was not going to be used at all. Rule 2 is your first line of defense against such effects.



            Rule 6: Use appropriate tools to read the compiler's mind, and expect to be surprised by the code it produces. Inspect the code yourself before forming theories about what makes something faster or slower.



            Rule 7: Reduce noise in your measurements. Run your benchmark on a quiet machine, and run it several times, discarding outliers. Use -Xbatch to serialize the compiler with the application, and consider setting -XX:CICompilerCount=1 to prevent the compiler from running in parallel with itself. Try your best to reduce GC overhead, set Xmx(large enough) equals Xms and use UseEpsilonGC if it is available.



            Rule 8: Use a library for your benchmark as it is probably more efficient and was already debugged for this sole purpose. Such as JMH, Caliper or Bill and Paul's Excellent UCSD Benchmarks for Java.






            share|improve this answer



















            • 5




              This was also an interesting article: ibm.com/developerworks/java/library/j-jtp12214
              – John Nilsson
              Jul 10 '10 at 22:29






            • 123




              Also, never use System.currentTimeMillis() unless you are OK with + or - 15 ms accuracy, which is typical on most OS + JVM combinations. Use System.nanoTime() instead.
              – Scott Carey
              Apr 22 '11 at 18:43








            • 5




              Some paper from javaOne: azulsystems.com/events/javaone_2009/session/…
              – bestsss
              Jun 5 '11 at 12:29






            • 86




              It should be noted that System.nanoTime() is not guaranteed to be more accurate than System.currentTimeMillis(). It is only guaranteed to be at least as accurate. It usually is substantially more accurate, however.
              – Gravity
              Jul 27 '11 at 8:00








            • 36




              The main reason why one must use System.nanoTime() instead of System.currentTimeMillis() is that the former is guaranteed to be monotonically increasing. Subtracting the values returned two currentTimeMillis invocations can actually give negative results, possibly because the system time was adjusted by some NTP daemon.
              – Waldheinz
              Mar 16 '15 at 10:51
















            708














            Tips about writing micro benchmarks from the creators of Java HotSpot:



            Rule 0: Read a reputable paper on JVMs and micro-benchmarking. A good one is Brian Goetz, 2005. Do not expect too much from micro-benchmarks; they measure only a limited range of JVM performance characteristics.



            Rule 1: Always include a warmup phase which runs your test kernel all the way through, enough to trigger all initializations and compilations before timing phase(s). (Fewer iterations is OK on the warmup phase. The rule of thumb is several tens of thousands of inner loop iterations.)



            Rule 2: Always run with -XX:+PrintCompilation, -verbose:gc, etc., so you can verify that the compiler and other parts of the JVM are not doing unexpected work during your timing phase.



            Rule 2.1: Print messages at the beginning and end of timing and warmup phases, so you can verify that there is no output from Rule 2 during the timing phase.



            Rule 3: Be aware of the difference between -client and -server, and OSR and regular compilations. The -XX:+PrintCompilation flag reports OSR compilations with an at-sign to denote the non-initial entry point, for example: Trouble$1::run @ 2 (41 bytes). Prefer server to client, and regular to OSR, if you are after best performance.



            Rule 4: Be aware of initialization effects. Do not print for the first time during your timing phase, since printing loads and initializes classes. Do not load new classes outside of the warmup phase (or final reporting phase), unless you are testing class loading specifically (and in that case load only the test classes). Rule 2 is your first line of defense against such effects.



            Rule 5: Be aware of deoptimization and recompilation effects. Do not take any code path for the first time in the timing phase, because the compiler may junk and recompile the code, based on an earlier optimistic assumption that the path was not going to be used at all. Rule 2 is your first line of defense against such effects.



            Rule 6: Use appropriate tools to read the compiler's mind, and expect to be surprised by the code it produces. Inspect the code yourself before forming theories about what makes something faster or slower.



            Rule 7: Reduce noise in your measurements. Run your benchmark on a quiet machine, and run it several times, discarding outliers. Use -Xbatch to serialize the compiler with the application, and consider setting -XX:CICompilerCount=1 to prevent the compiler from running in parallel with itself. Try your best to reduce GC overhead, set Xmx(large enough) equals Xms and use UseEpsilonGC if it is available.



            Rule 8: Use a library for your benchmark as it is probably more efficient and was already debugged for this sole purpose. Such as JMH, Caliper or Bill and Paul's Excellent UCSD Benchmarks for Java.






            share|improve this answer



















            • 5




              This was also an interesting article: ibm.com/developerworks/java/library/j-jtp12214
              – John Nilsson
              Jul 10 '10 at 22:29






            • 123




              Also, never use System.currentTimeMillis() unless you are OK with + or - 15 ms accuracy, which is typical on most OS + JVM combinations. Use System.nanoTime() instead.
              – Scott Carey
              Apr 22 '11 at 18:43








            • 5




              Some paper from javaOne: azulsystems.com/events/javaone_2009/session/…
              – bestsss
              Jun 5 '11 at 12:29






            • 86




              It should be noted that System.nanoTime() is not guaranteed to be more accurate than System.currentTimeMillis(). It is only guaranteed to be at least as accurate. It usually is substantially more accurate, however.
              – Gravity
              Jul 27 '11 at 8:00








            • 36




              The main reason why one must use System.nanoTime() instead of System.currentTimeMillis() is that the former is guaranteed to be monotonically increasing. Subtracting the values returned two currentTimeMillis invocations can actually give negative results, possibly because the system time was adjusted by some NTP daemon.
              – Waldheinz
              Mar 16 '15 at 10:51














            708












            708








            708






            Tips about writing micro benchmarks from the creators of Java HotSpot:



            Rule 0: Read a reputable paper on JVMs and micro-benchmarking. A good one is Brian Goetz, 2005. Do not expect too much from micro-benchmarks; they measure only a limited range of JVM performance characteristics.



            Rule 1: Always include a warmup phase which runs your test kernel all the way through, enough to trigger all initializations and compilations before timing phase(s). (Fewer iterations is OK on the warmup phase. The rule of thumb is several tens of thousands of inner loop iterations.)



            Rule 2: Always run with -XX:+PrintCompilation, -verbose:gc, etc., so you can verify that the compiler and other parts of the JVM are not doing unexpected work during your timing phase.



            Rule 2.1: Print messages at the beginning and end of timing and warmup phases, so you can verify that there is no output from Rule 2 during the timing phase.



            Rule 3: Be aware of the difference between -client and -server, and OSR and regular compilations. The -XX:+PrintCompilation flag reports OSR compilations with an at-sign to denote the non-initial entry point, for example: Trouble$1::run @ 2 (41 bytes). Prefer server to client, and regular to OSR, if you are after best performance.



            Rule 4: Be aware of initialization effects. Do not print for the first time during your timing phase, since printing loads and initializes classes. Do not load new classes outside of the warmup phase (or final reporting phase), unless you are testing class loading specifically (and in that case load only the test classes). Rule 2 is your first line of defense against such effects.



            Rule 5: Be aware of deoptimization and recompilation effects. Do not take any code path for the first time in the timing phase, because the compiler may junk and recompile the code, based on an earlier optimistic assumption that the path was not going to be used at all. Rule 2 is your first line of defense against such effects.



            Rule 6: Use appropriate tools to read the compiler's mind, and expect to be surprised by the code it produces. Inspect the code yourself before forming theories about what makes something faster or slower.



            Rule 7: Reduce noise in your measurements. Run your benchmark on a quiet machine, and run it several times, discarding outliers. Use -Xbatch to serialize the compiler with the application, and consider setting -XX:CICompilerCount=1 to prevent the compiler from running in parallel with itself. Try your best to reduce GC overhead, set Xmx(large enough) equals Xms and use UseEpsilonGC if it is available.



            Rule 8: Use a library for your benchmark as it is probably more efficient and was already debugged for this sole purpose. Such as JMH, Caliper or Bill and Paul's Excellent UCSD Benchmarks for Java.






            share|improve this answer














            Tips about writing micro benchmarks from the creators of Java HotSpot:



            Rule 0: Read a reputable paper on JVMs and micro-benchmarking. A good one is Brian Goetz, 2005. Do not expect too much from micro-benchmarks; they measure only a limited range of JVM performance characteristics.



            Rule 1: Always include a warmup phase which runs your test kernel all the way through, enough to trigger all initializations and compilations before timing phase(s). (Fewer iterations is OK on the warmup phase. The rule of thumb is several tens of thousands of inner loop iterations.)



            Rule 2: Always run with -XX:+PrintCompilation, -verbose:gc, etc., so you can verify that the compiler and other parts of the JVM are not doing unexpected work during your timing phase.



            Rule 2.1: Print messages at the beginning and end of timing and warmup phases, so you can verify that there is no output from Rule 2 during the timing phase.



            Rule 3: Be aware of the difference between -client and -server, and OSR and regular compilations. The -XX:+PrintCompilation flag reports OSR compilations with an at-sign to denote the non-initial entry point, for example: Trouble$1::run @ 2 (41 bytes). Prefer server to client, and regular to OSR, if you are after best performance.



            Rule 4: Be aware of initialization effects. Do not print for the first time during your timing phase, since printing loads and initializes classes. Do not load new classes outside of the warmup phase (or final reporting phase), unless you are testing class loading specifically (and in that case load only the test classes). Rule 2 is your first line of defense against such effects.



            Rule 5: Be aware of deoptimization and recompilation effects. Do not take any code path for the first time in the timing phase, because the compiler may junk and recompile the code, based on an earlier optimistic assumption that the path was not going to be used at all. Rule 2 is your first line of defense against such effects.



            Rule 6: Use appropriate tools to read the compiler's mind, and expect to be surprised by the code it produces. Inspect the code yourself before forming theories about what makes something faster or slower.



            Rule 7: Reduce noise in your measurements. Run your benchmark on a quiet machine, and run it several times, discarding outliers. Use -Xbatch to serialize the compiler with the application, and consider setting -XX:CICompilerCount=1 to prevent the compiler from running in parallel with itself. Try your best to reduce GC overhead, set Xmx(large enough) equals Xms and use UseEpsilonGC if it is available.



            Rule 8: Use a library for your benchmark as it is probably more efficient and was already debugged for this sole purpose. Such as JMH, Caliper or Bill and Paul's Excellent UCSD Benchmarks for Java.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Aug 9 '18 at 9:47


























            community wiki





            11 revs, 11 users 62%
            Eugene Kuleshov









            • 5




              This was also an interesting article: ibm.com/developerworks/java/library/j-jtp12214
              – John Nilsson
              Jul 10 '10 at 22:29






            • 123




              Also, never use System.currentTimeMillis() unless you are OK with + or - 15 ms accuracy, which is typical on most OS + JVM combinations. Use System.nanoTime() instead.
              – Scott Carey
              Apr 22 '11 at 18:43








            • 5




              Some paper from javaOne: azulsystems.com/events/javaone_2009/session/…
              – bestsss
              Jun 5 '11 at 12:29






            • 86




              It should be noted that System.nanoTime() is not guaranteed to be more accurate than System.currentTimeMillis(). It is only guaranteed to be at least as accurate. It usually is substantially more accurate, however.
              – Gravity
              Jul 27 '11 at 8:00








            • 36




              The main reason why one must use System.nanoTime() instead of System.currentTimeMillis() is that the former is guaranteed to be monotonically increasing. Subtracting the values returned two currentTimeMillis invocations can actually give negative results, possibly because the system time was adjusted by some NTP daemon.
              – Waldheinz
              Mar 16 '15 at 10:51














            • 5




              This was also an interesting article: ibm.com/developerworks/java/library/j-jtp12214
              – John Nilsson
              Jul 10 '10 at 22:29






            • 123




              Also, never use System.currentTimeMillis() unless you are OK with + or - 15 ms accuracy, which is typical on most OS + JVM combinations. Use System.nanoTime() instead.
              – Scott Carey
              Apr 22 '11 at 18:43








            • 5




              Some paper from javaOne: azulsystems.com/events/javaone_2009/session/…
              – bestsss
              Jun 5 '11 at 12:29






            • 86




              It should be noted that System.nanoTime() is not guaranteed to be more accurate than System.currentTimeMillis(). It is only guaranteed to be at least as accurate. It usually is substantially more accurate, however.
              – Gravity
              Jul 27 '11 at 8:00








            • 36




              The main reason why one must use System.nanoTime() instead of System.currentTimeMillis() is that the former is guaranteed to be monotonically increasing. Subtracting the values returned two currentTimeMillis invocations can actually give negative results, possibly because the system time was adjusted by some NTP daemon.
              – Waldheinz
              Mar 16 '15 at 10:51








            5




            5




            This was also an interesting article: ibm.com/developerworks/java/library/j-jtp12214
            – John Nilsson
            Jul 10 '10 at 22:29




            This was also an interesting article: ibm.com/developerworks/java/library/j-jtp12214
            – John Nilsson
            Jul 10 '10 at 22:29




            123




            123




            Also, never use System.currentTimeMillis() unless you are OK with + or - 15 ms accuracy, which is typical on most OS + JVM combinations. Use System.nanoTime() instead.
            – Scott Carey
            Apr 22 '11 at 18:43






            Also, never use System.currentTimeMillis() unless you are OK with + or - 15 ms accuracy, which is typical on most OS + JVM combinations. Use System.nanoTime() instead.
            – Scott Carey
            Apr 22 '11 at 18:43






            5




            5




            Some paper from javaOne: azulsystems.com/events/javaone_2009/session/…
            – bestsss
            Jun 5 '11 at 12:29




            Some paper from javaOne: azulsystems.com/events/javaone_2009/session/…
            – bestsss
            Jun 5 '11 at 12:29




            86




            86




            It should be noted that System.nanoTime() is not guaranteed to be more accurate than System.currentTimeMillis(). It is only guaranteed to be at least as accurate. It usually is substantially more accurate, however.
            – Gravity
            Jul 27 '11 at 8:00






            It should be noted that System.nanoTime() is not guaranteed to be more accurate than System.currentTimeMillis(). It is only guaranteed to be at least as accurate. It usually is substantially more accurate, however.
            – Gravity
            Jul 27 '11 at 8:00






            36




            36




            The main reason why one must use System.nanoTime() instead of System.currentTimeMillis() is that the former is guaranteed to be monotonically increasing. Subtracting the values returned two currentTimeMillis invocations can actually give negative results, possibly because the system time was adjusted by some NTP daemon.
            – Waldheinz
            Mar 16 '15 at 10:51




            The main reason why one must use System.nanoTime() instead of System.currentTimeMillis() is that the former is guaranteed to be monotonically increasing. Subtracting the values returned two currentTimeMillis invocations can actually give negative results, possibly because the system time was adjusted by some NTP daemon.
            – Waldheinz
            Mar 16 '15 at 10:51













            223














            I know this question has been marked as answered but I wanted to mention two libraries that enable us to write micro benchmarks



            Caliper from Google



            Getting started tutorials




            1. http://codingjunkie.net/micro-benchmarking-with-caliper/

            2. http://vertexlabs.co.uk/blog/caliper


            JMH from OpenJDK



            Getting started tutorials




            1. Avoiding Benchmarking Pitfalls on the JVM

            2. http://nitschinger.at/Using-JMH-for-Java-Microbenchmarking

            3. http://java-performance.info/jmh/






            share|improve this answer



















            • 34




              +1 it could have been added as Rule 8 of the accepted answer: Rule 8: because so many things can go wrong, you should probably use an existing library rather than trying to do it yourself!
              – assylias
              Dec 6 '12 at 23:58






            • 7




              @Pangea jmh is probably superior to Caliper nowadays, See also: groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/…
              – assylias
              Dec 3 '15 at 9:49
















            223














            I know this question has been marked as answered but I wanted to mention two libraries that enable us to write micro benchmarks



            Caliper from Google



            Getting started tutorials




            1. http://codingjunkie.net/micro-benchmarking-with-caliper/

            2. http://vertexlabs.co.uk/blog/caliper


            JMH from OpenJDK



            Getting started tutorials




            1. Avoiding Benchmarking Pitfalls on the JVM

            2. http://nitschinger.at/Using-JMH-for-Java-Microbenchmarking

            3. http://java-performance.info/jmh/






            share|improve this answer



















            • 34




              +1 it could have been added as Rule 8 of the accepted answer: Rule 8: because so many things can go wrong, you should probably use an existing library rather than trying to do it yourself!
              – assylias
              Dec 6 '12 at 23:58






            • 7




              @Pangea jmh is probably superior to Caliper nowadays, See also: groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/…
              – assylias
              Dec 3 '15 at 9:49














            223












            223








            223






            I know this question has been marked as answered but I wanted to mention two libraries that enable us to write micro benchmarks



            Caliper from Google



            Getting started tutorials




            1. http://codingjunkie.net/micro-benchmarking-with-caliper/

            2. http://vertexlabs.co.uk/blog/caliper


            JMH from OpenJDK



            Getting started tutorials




            1. Avoiding Benchmarking Pitfalls on the JVM

            2. http://nitschinger.at/Using-JMH-for-Java-Microbenchmarking

            3. http://java-performance.info/jmh/






            share|improve this answer














            I know this question has been marked as answered but I wanted to mention two libraries that enable us to write micro benchmarks



            Caliper from Google



            Getting started tutorials




            1. http://codingjunkie.net/micro-benchmarking-with-caliper/

            2. http://vertexlabs.co.uk/blog/caliper


            JMH from OpenJDK



            Getting started tutorials




            1. Avoiding Benchmarking Pitfalls on the JVM

            2. http://nitschinger.at/Using-JMH-for-Java-Microbenchmarking

            3. http://java-performance.info/jmh/







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Mar 28 '18 at 15:10









            agilob

            3,96611730




            3,96611730










            answered Dec 18 '10 at 23:35









            Aravind R. YarramAravind R. Yarram

            60.8k34186268




            60.8k34186268








            • 34




              +1 it could have been added as Rule 8 of the accepted answer: Rule 8: because so many things can go wrong, you should probably use an existing library rather than trying to do it yourself!
              – assylias
              Dec 6 '12 at 23:58






            • 7




              @Pangea jmh is probably superior to Caliper nowadays, See also: groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/…
              – assylias
              Dec 3 '15 at 9:49














            • 34




              +1 it could have been added as Rule 8 of the accepted answer: Rule 8: because so many things can go wrong, you should probably use an existing library rather than trying to do it yourself!
              – assylias
              Dec 6 '12 at 23:58






            • 7




              @Pangea jmh is probably superior to Caliper nowadays, See also: groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/…
              – assylias
              Dec 3 '15 at 9:49








            34




            34




            +1 it could have been added as Rule 8 of the accepted answer: Rule 8: because so many things can go wrong, you should probably use an existing library rather than trying to do it yourself!
            – assylias
            Dec 6 '12 at 23:58




            +1 it could have been added as Rule 8 of the accepted answer: Rule 8: because so many things can go wrong, you should probably use an existing library rather than trying to do it yourself!
            – assylias
            Dec 6 '12 at 23:58




            7




            7




            @Pangea jmh is probably superior to Caliper nowadays, See also: groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/…
            – assylias
            Dec 3 '15 at 9:49




            @Pangea jmh is probably superior to Caliper nowadays, See also: groups.google.com/forum/#!msg/mechanical-sympathy/m4opvy4xq3U/…
            – assylias
            Dec 3 '15 at 9:49











            78














            Important things for Java benchmarks are:




            • Warm up the JIT first by running the code several times before timing it

            • Make sure you run it for long enough to be able to measure the results in seconds or (better) tens of seconds

            • While you can't call System.gc() between iterations, it's a good idea to run it between tests, so that each test will hopefully get a "clean" memory space to work with. (Yes, gc() is more of a hint than a guarantee, but it's very likely that it really will garbage collect in my experience.)

            • I like to display iterations and time, and a score of time/iteration which can be scaled such that the "best" algorithm gets a score of 1.0 and others are scored in a relative fashion. This means you can run all algorithms for a longish time, varying both number of iterations and time, but still getting comparable results.


            I'm just in the process of blogging about the design of a benchmarking framework in .NET. I've got a couple of earlier posts which may be able to give you some ideas - not everything will be appropriate, of course, but some of it may be.






            share|improve this answer



















            • 3




              Minor nitpick: IMO "so that each test gets" should be "so that each test might get" since the former gives the impression that calling gc always frees up unused memory.
              – Sanjay T. Sharma
              Apr 20 '13 at 6:52












            • @SanjayT.Sharma: Well, the intention is that it actually does. While it's not strictly guaranteed, it's actually a pretty strong hint. Will edit to be clearer.
              – Jon Skeet
              Apr 20 '13 at 8:02






            • 1




              I don't agree with calling System.gc(). It is a hint, that's all. Not even "it will hopefully do something". You should never ever call it. This is programming, not art.
              – gyorgyabraham
              Jun 14 '13 at 10:38






            • 13




              @gyabraham: Yes, it's a hint - but it's one which I've observed to usually be taken. So if you don't like using System.gc(), how do you propose to minimize garbage collection in one test due to objects created in previous tests? I'm pragmatic, not dogmatic.
              – Jon Skeet
              Jun 14 '13 at 10:58






            • 9




              @gyabraham: I don't know what you mean by "great fallback". Can you elaborate, and again - do you have a proposal to give better results? I did explicitly say that it's not a guarantee...
              – Jon Skeet
              Jun 14 '13 at 17:44
















            78














            Important things for Java benchmarks are:




            • Warm up the JIT first by running the code several times before timing it

            • Make sure you run it for long enough to be able to measure the results in seconds or (better) tens of seconds

            • While you can't call System.gc() between iterations, it's a good idea to run it between tests, so that each test will hopefully get a "clean" memory space to work with. (Yes, gc() is more of a hint than a guarantee, but it's very likely that it really will garbage collect in my experience.)

            • I like to display iterations and time, and a score of time/iteration which can be scaled such that the "best" algorithm gets a score of 1.0 and others are scored in a relative fashion. This means you can run all algorithms for a longish time, varying both number of iterations and time, but still getting comparable results.


            I'm just in the process of blogging about the design of a benchmarking framework in .NET. I've got a couple of earlier posts which may be able to give you some ideas - not everything will be appropriate, of course, but some of it may be.






            share|improve this answer



















            • 3




              Minor nitpick: IMO "so that each test gets" should be "so that each test might get" since the former gives the impression that calling gc always frees up unused memory.
              – Sanjay T. Sharma
              Apr 20 '13 at 6:52












            • @SanjayT.Sharma: Well, the intention is that it actually does. While it's not strictly guaranteed, it's actually a pretty strong hint. Will edit to be clearer.
              – Jon Skeet
              Apr 20 '13 at 8:02






            • 1




              I don't agree with calling System.gc(). It is a hint, that's all. Not even "it will hopefully do something". You should never ever call it. This is programming, not art.
              – gyorgyabraham
              Jun 14 '13 at 10:38






            • 13




              @gyabraham: Yes, it's a hint - but it's one which I've observed to usually be taken. So if you don't like using System.gc(), how do you propose to minimize garbage collection in one test due to objects created in previous tests? I'm pragmatic, not dogmatic.
              – Jon Skeet
              Jun 14 '13 at 10:58






            • 9




              @gyabraham: I don't know what you mean by "great fallback". Can you elaborate, and again - do you have a proposal to give better results? I did explicitly say that it's not a guarantee...
              – Jon Skeet
              Jun 14 '13 at 17:44














            78












            78








            78






            Important things for Java benchmarks are:




            • Warm up the JIT first by running the code several times before timing it

            • Make sure you run it for long enough to be able to measure the results in seconds or (better) tens of seconds

            • While you can't call System.gc() between iterations, it's a good idea to run it between tests, so that each test will hopefully get a "clean" memory space to work with. (Yes, gc() is more of a hint than a guarantee, but it's very likely that it really will garbage collect in my experience.)

            • I like to display iterations and time, and a score of time/iteration which can be scaled such that the "best" algorithm gets a score of 1.0 and others are scored in a relative fashion. This means you can run all algorithms for a longish time, varying both number of iterations and time, but still getting comparable results.


            I'm just in the process of blogging about the design of a benchmarking framework in .NET. I've got a couple of earlier posts which may be able to give you some ideas - not everything will be appropriate, of course, but some of it may be.






            share|improve this answer














            Important things for Java benchmarks are:




            • Warm up the JIT first by running the code several times before timing it

            • Make sure you run it for long enough to be able to measure the results in seconds or (better) tens of seconds

            • While you can't call System.gc() between iterations, it's a good idea to run it between tests, so that each test will hopefully get a "clean" memory space to work with. (Yes, gc() is more of a hint than a guarantee, but it's very likely that it really will garbage collect in my experience.)

            • I like to display iterations and time, and a score of time/iteration which can be scaled such that the "best" algorithm gets a score of 1.0 and others are scored in a relative fashion. This means you can run all algorithms for a longish time, varying both number of iterations and time, but still getting comparable results.


            I'm just in the process of blogging about the design of a benchmarking framework in .NET. I've got a couple of earlier posts which may be able to give you some ideas - not everything will be appropriate, of course, but some of it may be.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Apr 20 '13 at 8:02

























            answered Feb 2 '09 at 17:46









            Jon SkeetJon Skeet

            1079k67878858410




            1079k67878858410








            • 3




              Minor nitpick: IMO "so that each test gets" should be "so that each test might get" since the former gives the impression that calling gc always frees up unused memory.
              – Sanjay T. Sharma
              Apr 20 '13 at 6:52












            • @SanjayT.Sharma: Well, the intention is that it actually does. While it's not strictly guaranteed, it's actually a pretty strong hint. Will edit to be clearer.
              – Jon Skeet
              Apr 20 '13 at 8:02






            • 1




              I don't agree with calling System.gc(). It is a hint, that's all. Not even "it will hopefully do something". You should never ever call it. This is programming, not art.
              – gyorgyabraham
              Jun 14 '13 at 10:38






            • 13




              @gyabraham: Yes, it's a hint - but it's one which I've observed to usually be taken. So if you don't like using System.gc(), how do you propose to minimize garbage collection in one test due to objects created in previous tests? I'm pragmatic, not dogmatic.
              – Jon Skeet
              Jun 14 '13 at 10:58






            • 9




              @gyabraham: I don't know what you mean by "great fallback". Can you elaborate, and again - do you have a proposal to give better results? I did explicitly say that it's not a guarantee...
              – Jon Skeet
              Jun 14 '13 at 17:44














            • 3




              Minor nitpick: IMO "so that each test gets" should be "so that each test might get" since the former gives the impression that calling gc always frees up unused memory.
              – Sanjay T. Sharma
              Apr 20 '13 at 6:52












            • @SanjayT.Sharma: Well, the intention is that it actually does. While it's not strictly guaranteed, it's actually a pretty strong hint. Will edit to be clearer.
              – Jon Skeet
              Apr 20 '13 at 8:02






            • 1




              I don't agree with calling System.gc(). It is a hint, that's all. Not even "it will hopefully do something". You should never ever call it. This is programming, not art.
              – gyorgyabraham
              Jun 14 '13 at 10:38






            • 13




              @gyabraham: Yes, it's a hint - but it's one which I've observed to usually be taken. So if you don't like using System.gc(), how do you propose to minimize garbage collection in one test due to objects created in previous tests? I'm pragmatic, not dogmatic.
              – Jon Skeet
              Jun 14 '13 at 10:58






            • 9




              @gyabraham: I don't know what you mean by "great fallback". Can you elaborate, and again - do you have a proposal to give better results? I did explicitly say that it's not a guarantee...
              – Jon Skeet
              Jun 14 '13 at 17:44








            3




            3




            Minor nitpick: IMO "so that each test gets" should be "so that each test might get" since the former gives the impression that calling gc always frees up unused memory.
            – Sanjay T. Sharma
            Apr 20 '13 at 6:52






            Minor nitpick: IMO "so that each test gets" should be "so that each test might get" since the former gives the impression that calling gc always frees up unused memory.
            – Sanjay T. Sharma
            Apr 20 '13 at 6:52














            @SanjayT.Sharma: Well, the intention is that it actually does. While it's not strictly guaranteed, it's actually a pretty strong hint. Will edit to be clearer.
            – Jon Skeet
            Apr 20 '13 at 8:02




            @SanjayT.Sharma: Well, the intention is that it actually does. While it's not strictly guaranteed, it's actually a pretty strong hint. Will edit to be clearer.
            – Jon Skeet
            Apr 20 '13 at 8:02




            1




            1




            I don't agree with calling System.gc(). It is a hint, that's all. Not even "it will hopefully do something". You should never ever call it. This is programming, not art.
            – gyorgyabraham
            Jun 14 '13 at 10:38




            I don't agree with calling System.gc(). It is a hint, that's all. Not even "it will hopefully do something". You should never ever call it. This is programming, not art.
            – gyorgyabraham
            Jun 14 '13 at 10:38




            13




            13




            @gyabraham: Yes, it's a hint - but it's one which I've observed to usually be taken. So if you don't like using System.gc(), how do you propose to minimize garbage collection in one test due to objects created in previous tests? I'm pragmatic, not dogmatic.
            – Jon Skeet
            Jun 14 '13 at 10:58




            @gyabraham: Yes, it's a hint - but it's one which I've observed to usually be taken. So if you don't like using System.gc(), how do you propose to minimize garbage collection in one test due to objects created in previous tests? I'm pragmatic, not dogmatic.
            – Jon Skeet
            Jun 14 '13 at 10:58




            9




            9




            @gyabraham: I don't know what you mean by "great fallback". Can you elaborate, and again - do you have a proposal to give better results? I did explicitly say that it's not a guarantee...
            – Jon Skeet
            Jun 14 '13 at 17:44




            @gyabraham: I don't know what you mean by "great fallback". Can you elaborate, and again - do you have a proposal to give better results? I did explicitly say that it's not a guarantee...
            – Jon Skeet
            Jun 14 '13 at 17:44











            43














            jmh is a recent addition to OpenJDK and has been written by some performance engineers from Oracle. Certainly worth having a look.




            The jmh is a Java harness for building, running, and analysing nano/micro/macro benchmarks written in Java and other languages targetting the JVM.




            Very interesting pieces of information buried in the sample tests comments.



            See also:




            • Avoiding Benchmarking Pitfalls on the JVM


            • Discussion on the main strengths of jmh.






            share|improve this answer



















            • 1




              See also this blog post: psy-lob-saw.blogspot.com/2013/04/… for details on getting started with JMH.
              – Nitsan Wakart
              May 2 '13 at 15:41












            • FYI, JEP 230: Microbenchmark Suite is an OpenJDK proposal based on this Java Microbenchmark Harness (JMH) project. Did not make the cut for Java 9 but may be added later.
              – Basil Bourque
              Jul 1 '16 at 23:03


















            43














            jmh is a recent addition to OpenJDK and has been written by some performance engineers from Oracle. Certainly worth having a look.




            The jmh is a Java harness for building, running, and analysing nano/micro/macro benchmarks written in Java and other languages targetting the JVM.




            Very interesting pieces of information buried in the sample tests comments.



            See also:




            • Avoiding Benchmarking Pitfalls on the JVM


            • Discussion on the main strengths of jmh.






            share|improve this answer



















            • 1




              See also this blog post: psy-lob-saw.blogspot.com/2013/04/… for details on getting started with JMH.
              – Nitsan Wakart
              May 2 '13 at 15:41












            • FYI, JEP 230: Microbenchmark Suite is an OpenJDK proposal based on this Java Microbenchmark Harness (JMH) project. Did not make the cut for Java 9 but may be added later.
              – Basil Bourque
              Jul 1 '16 at 23:03
















            43












            43








            43






            jmh is a recent addition to OpenJDK and has been written by some performance engineers from Oracle. Certainly worth having a look.




            The jmh is a Java harness for building, running, and analysing nano/micro/macro benchmarks written in Java and other languages targetting the JVM.




            Very interesting pieces of information buried in the sample tests comments.



            See also:




            • Avoiding Benchmarking Pitfalls on the JVM


            • Discussion on the main strengths of jmh.






            share|improve this answer














            jmh is a recent addition to OpenJDK and has been written by some performance engineers from Oracle. Certainly worth having a look.




            The jmh is a Java harness for building, running, and analysing nano/micro/macro benchmarks written in Java and other languages targetting the JVM.




            Very interesting pieces of information buried in the sample tests comments.



            See also:




            • Avoiding Benchmarking Pitfalls on the JVM


            • Discussion on the main strengths of jmh.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Dec 21 '15 at 7:47

























            answered Apr 3 '13 at 12:32









            assyliasassylias

            245k49509648




            245k49509648








            • 1




              See also this blog post: psy-lob-saw.blogspot.com/2013/04/… for details on getting started with JMH.
              – Nitsan Wakart
              May 2 '13 at 15:41












            • FYI, JEP 230: Microbenchmark Suite is an OpenJDK proposal based on this Java Microbenchmark Harness (JMH) project. Did not make the cut for Java 9 but may be added later.
              – Basil Bourque
              Jul 1 '16 at 23:03
















            • 1




              See also this blog post: psy-lob-saw.blogspot.com/2013/04/… for details on getting started with JMH.
              – Nitsan Wakart
              May 2 '13 at 15:41












            • FYI, JEP 230: Microbenchmark Suite is an OpenJDK proposal based on this Java Microbenchmark Harness (JMH) project. Did not make the cut for Java 9 but may be added later.
              – Basil Bourque
              Jul 1 '16 at 23:03










            1




            1




            See also this blog post: psy-lob-saw.blogspot.com/2013/04/… for details on getting started with JMH.
            – Nitsan Wakart
            May 2 '13 at 15:41






            See also this blog post: psy-lob-saw.blogspot.com/2013/04/… for details on getting started with JMH.
            – Nitsan Wakart
            May 2 '13 at 15:41














            FYI, JEP 230: Microbenchmark Suite is an OpenJDK proposal based on this Java Microbenchmark Harness (JMH) project. Did not make the cut for Java 9 but may be added later.
            – Basil Bourque
            Jul 1 '16 at 23:03






            FYI, JEP 230: Microbenchmark Suite is an OpenJDK proposal based on this Java Microbenchmark Harness (JMH) project. Did not make the cut for Java 9 but may be added later.
            – Basil Bourque
            Jul 1 '16 at 23:03













            17















            Should the benchmark measure time/iteration or iterations/time, and why?




            It depends on what you are trying to test. If you are interested in latency, use time/iteration and if you are interested in throughput use iterations/time.






            share|improve this answer


























              17















              Should the benchmark measure time/iteration or iterations/time, and why?




              It depends on what you are trying to test. If you are interested in latency, use time/iteration and if you are interested in throughput use iterations/time.






              share|improve this answer
























                17












                17








                17







                Should the benchmark measure time/iteration or iterations/time, and why?




                It depends on what you are trying to test. If you are interested in latency, use time/iteration and if you are interested in throughput use iterations/time.






                share|improve this answer













                Should the benchmark measure time/iteration or iterations/time, and why?




                It depends on what you are trying to test. If you are interested in latency, use time/iteration and if you are interested in throughput use iterations/time.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Feb 2 '09 at 19:54









                Peter LawreyPeter Lawrey

                441k55559962




                441k55559962























                    14














                    Make sure you somehow use results which are computed in benchmarked code. Otherwise your code can be optimized away.






                    share|improve this answer


























                      14














                      Make sure you somehow use results which are computed in benchmarked code. Otherwise your code can be optimized away.






                      share|improve this answer
























                        14












                        14








                        14






                        Make sure you somehow use results which are computed in benchmarked code. Otherwise your code can be optimized away.






                        share|improve this answer












                        Make sure you somehow use results which are computed in benchmarked code. Otherwise your code can be optimized away.







                        share|improve this answer












                        share|improve this answer



                        share|improve this answer










                        answered Feb 2 '09 at 18:00









                        Peter ŠtibranýPeter Štibraný

                        27k874111




                        27k874111























                            12














                            If you are trying to compare two algorithms, do at least two benchmarks on each, alternating the order. i.e.:



                            for(i=1..n)
                            alg1();
                            for(i=1..n)
                            alg2();
                            for(i=1..n)
                            alg2();
                            for(i=1..n)
                            alg1();


                            I have found some noticeable differences (5-10% sometimes) in the runtime of the same algorithm in different passes..



                            Also, make sure that n is very large, so that the runtime of each loop is at the very least 10 seconds or so. The more iterations, the more significant figures in your benchmark time and the more reliable that data is.






                            share|improve this answer

















                            • 5




                              Naturally changing the order influences the runtime. JVM-optimizations and caching-effects are going to work here. Better is to 'warm up' the JVM-optimization, mak multiple runs and benchmark every test in a different JVM.
                              – Mnementh
                              Feb 2 '09 at 18:04
















                            12














                            If you are trying to compare two algorithms, do at least two benchmarks on each, alternating the order. i.e.:



                            for(i=1..n)
                            alg1();
                            for(i=1..n)
                            alg2();
                            for(i=1..n)
                            alg2();
                            for(i=1..n)
                            alg1();


                            I have found some noticeable differences (5-10% sometimes) in the runtime of the same algorithm in different passes..



                            Also, make sure that n is very large, so that the runtime of each loop is at the very least 10 seconds or so. The more iterations, the more significant figures in your benchmark time and the more reliable that data is.






                            share|improve this answer

















                            • 5




                              Naturally changing the order influences the runtime. JVM-optimizations and caching-effects are going to work here. Better is to 'warm up' the JVM-optimization, mak multiple runs and benchmark every test in a different JVM.
                              – Mnementh
                              Feb 2 '09 at 18:04














                            12












                            12








                            12






                            If you are trying to compare two algorithms, do at least two benchmarks on each, alternating the order. i.e.:



                            for(i=1..n)
                            alg1();
                            for(i=1..n)
                            alg2();
                            for(i=1..n)
                            alg2();
                            for(i=1..n)
                            alg1();


                            I have found some noticeable differences (5-10% sometimes) in the runtime of the same algorithm in different passes..



                            Also, make sure that n is very large, so that the runtime of each loop is at the very least 10 seconds or so. The more iterations, the more significant figures in your benchmark time and the more reliable that data is.






                            share|improve this answer












                            If you are trying to compare two algorithms, do at least two benchmarks on each, alternating the order. i.e.:



                            for(i=1..n)
                            alg1();
                            for(i=1..n)
                            alg2();
                            for(i=1..n)
                            alg2();
                            for(i=1..n)
                            alg1();


                            I have found some noticeable differences (5-10% sometimes) in the runtime of the same algorithm in different passes..



                            Also, make sure that n is very large, so that the runtime of each loop is at the very least 10 seconds or so. The more iterations, the more significant figures in your benchmark time and the more reliable that data is.







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Feb 2 '09 at 17:57









                            KipKip

                            66.1k78205237




                            66.1k78205237








                            • 5




                              Naturally changing the order influences the runtime. JVM-optimizations and caching-effects are going to work here. Better is to 'warm up' the JVM-optimization, mak multiple runs and benchmark every test in a different JVM.
                              – Mnementh
                              Feb 2 '09 at 18:04














                            • 5




                              Naturally changing the order influences the runtime. JVM-optimizations and caching-effects are going to work here. Better is to 'warm up' the JVM-optimization, mak multiple runs and benchmark every test in a different JVM.
                              – Mnementh
                              Feb 2 '09 at 18:04








                            5




                            5




                            Naturally changing the order influences the runtime. JVM-optimizations and caching-effects are going to work here. Better is to 'warm up' the JVM-optimization, mak multiple runs and benchmark every test in a different JVM.
                            – Mnementh
                            Feb 2 '09 at 18:04




                            Naturally changing the order influences the runtime. JVM-optimizations and caching-effects are going to work here. Better is to 'warm up' the JVM-optimization, mak multiple runs and benchmark every test in a different JVM.
                            – Mnementh
                            Feb 2 '09 at 18:04











                            12














                            There are many possible pitfalls for writing micro-benchmarks in Java.



                            First: You have to calculate with all sorts of events that take time more or less random: Garbage collection, caching effects (of OS for files and of CPU for memory), IO etc.



                            Second: You cannot trust the accuracy of the measured times for very short intervals.



                            Third: The JVM optimizes your code while executing. So different runs in the same JVM-instance will become faster and faster.



                            My recommendations: Make your benchmark run some seconds, that is more reliable than a runtime over milliseconds. Warm up the JVM (means running the benchmark at least once without measuring, that the JVM can run optimizations). And run your benchmark multiple times (maybe 5 times) and take the median-value. Run every micro-benchmark in a new JVM-instance (call for every benchmark new Java) otherwise optimization effects of the JVM can influence later running tests. Don't execute things, that aren't executed in the warmup-phase (as this could trigger class-load and recompilation).






                            share|improve this answer




























                              12














                              There are many possible pitfalls for writing micro-benchmarks in Java.



                              First: You have to calculate with all sorts of events that take time more or less random: Garbage collection, caching effects (of OS for files and of CPU for memory), IO etc.



                              Second: You cannot trust the accuracy of the measured times for very short intervals.



                              Third: The JVM optimizes your code while executing. So different runs in the same JVM-instance will become faster and faster.



                              My recommendations: Make your benchmark run some seconds, that is more reliable than a runtime over milliseconds. Warm up the JVM (means running the benchmark at least once without measuring, that the JVM can run optimizations). And run your benchmark multiple times (maybe 5 times) and take the median-value. Run every micro-benchmark in a new JVM-instance (call for every benchmark new Java) otherwise optimization effects of the JVM can influence later running tests. Don't execute things, that aren't executed in the warmup-phase (as this could trigger class-load and recompilation).






                              share|improve this answer


























                                12












                                12








                                12






                                There are many possible pitfalls for writing micro-benchmarks in Java.



                                First: You have to calculate with all sorts of events that take time more or less random: Garbage collection, caching effects (of OS for files and of CPU for memory), IO etc.



                                Second: You cannot trust the accuracy of the measured times for very short intervals.



                                Third: The JVM optimizes your code while executing. So different runs in the same JVM-instance will become faster and faster.



                                My recommendations: Make your benchmark run some seconds, that is more reliable than a runtime over milliseconds. Warm up the JVM (means running the benchmark at least once without measuring, that the JVM can run optimizations). And run your benchmark multiple times (maybe 5 times) and take the median-value. Run every micro-benchmark in a new JVM-instance (call for every benchmark new Java) otherwise optimization effects of the JVM can influence later running tests. Don't execute things, that aren't executed in the warmup-phase (as this could trigger class-load and recompilation).






                                share|improve this answer














                                There are many possible pitfalls for writing micro-benchmarks in Java.



                                First: You have to calculate with all sorts of events that take time more or less random: Garbage collection, caching effects (of OS for files and of CPU for memory), IO etc.



                                Second: You cannot trust the accuracy of the measured times for very short intervals.



                                Third: The JVM optimizes your code while executing. So different runs in the same JVM-instance will become faster and faster.



                                My recommendations: Make your benchmark run some seconds, that is more reliable than a runtime over milliseconds. Warm up the JVM (means running the benchmark at least once without measuring, that the JVM can run optimizations). And run your benchmark multiple times (maybe 5 times) and take the median-value. Run every micro-benchmark in a new JVM-instance (call for every benchmark new Java) otherwise optimization effects of the JVM can influence later running tests. Don't execute things, that aren't executed in the warmup-phase (as this could trigger class-load and recompilation).







                                share|improve this answer














                                share|improve this answer



                                share|improve this answer








                                edited Jun 23 '09 at 11:32

























                                answered Feb 2 '09 at 17:46









                                MnementhMnementh

                                30.6k38127195




                                30.6k38127195























                                    7














                                    It should also be noted that it might also be important to analyze the results of the micro benchmark when comparing different implementations. Therefore a significance test should be made.



                                    This is because implementation A might be faster during most of the runs of the benchmark than implementation B. But A might also have a higher spread, so the measured performance benefit of A won't be of any significance when compared with B.



                                    So it is also important to write and run a micro benchmark correctly, but also to analyze it correctly.






                                    share|improve this answer


























                                      7














                                      It should also be noted that it might also be important to analyze the results of the micro benchmark when comparing different implementations. Therefore a significance test should be made.



                                      This is because implementation A might be faster during most of the runs of the benchmark than implementation B. But A might also have a higher spread, so the measured performance benefit of A won't be of any significance when compared with B.



                                      So it is also important to write and run a micro benchmark correctly, but also to analyze it correctly.






                                      share|improve this answer
























                                        7












                                        7








                                        7






                                        It should also be noted that it might also be important to analyze the results of the micro benchmark when comparing different implementations. Therefore a significance test should be made.



                                        This is because implementation A might be faster during most of the runs of the benchmark than implementation B. But A might also have a higher spread, so the measured performance benefit of A won't be of any significance when compared with B.



                                        So it is also important to write and run a micro benchmark correctly, but also to analyze it correctly.






                                        share|improve this answer












                                        It should also be noted that it might also be important to analyze the results of the micro benchmark when comparing different implementations. Therefore a significance test should be made.



                                        This is because implementation A might be faster during most of the runs of the benchmark than implementation B. But A might also have a higher spread, so the measured performance benefit of A won't be of any significance when compared with B.



                                        So it is also important to write and run a micro benchmark correctly, but also to analyze it correctly.







                                        share|improve this answer












                                        share|improve this answer



                                        share|improve this answer










                                        answered Jan 21 '13 at 14:04









                                        SpaceTruckerSpaceTrucker

                                        8,69253778




                                        8,69253778























                                            6














                                            http://opt.sourceforge.net/ Java Micro Benchmark - control tasks required to determine the comparative performance characteristics of the computer system on different platforms. Can be used to guide optimization decisions and to compare different Java implementations.






                                            share|improve this answer

















                                            • 1




                                              Seems to just benchmark the JVM + hardware, not an arbitrary piece of Java code.
                                              – Stefan L
                                              Feb 29 '12 at 22:05
















                                            6














                                            http://opt.sourceforge.net/ Java Micro Benchmark - control tasks required to determine the comparative performance characteristics of the computer system on different platforms. Can be used to guide optimization decisions and to compare different Java implementations.






                                            share|improve this answer

















                                            • 1




                                              Seems to just benchmark the JVM + hardware, not an arbitrary piece of Java code.
                                              – Stefan L
                                              Feb 29 '12 at 22:05














                                            6












                                            6








                                            6






                                            http://opt.sourceforge.net/ Java Micro Benchmark - control tasks required to determine the comparative performance characteristics of the computer system on different platforms. Can be used to guide optimization decisions and to compare different Java implementations.






                                            share|improve this answer












                                            http://opt.sourceforge.net/ Java Micro Benchmark - control tasks required to determine the comparative performance characteristics of the computer system on different platforms. Can be used to guide optimization decisions and to compare different Java implementations.







                                            share|improve this answer












                                            share|improve this answer



                                            share|improve this answer










                                            answered Dec 18 '10 at 23:22









                                            YuriyYuriy

                                            7711




                                            7711








                                            • 1




                                              Seems to just benchmark the JVM + hardware, not an arbitrary piece of Java code.
                                              – Stefan L
                                              Feb 29 '12 at 22:05














                                            • 1




                                              Seems to just benchmark the JVM + hardware, not an arbitrary piece of Java code.
                                              – Stefan L
                                              Feb 29 '12 at 22:05








                                            1




                                            1




                                            Seems to just benchmark the JVM + hardware, not an arbitrary piece of Java code.
                                            – Stefan L
                                            Feb 29 '12 at 22:05




                                            Seems to just benchmark the JVM + hardware, not an arbitrary piece of Java code.
                                            – Stefan L
                                            Feb 29 '12 at 22:05











                                            5














                                            To add to the other excellent advice, I'd also be mindful of the following:



                                            For some CPUs (e.g. Intel Core i5 range with TurboBoost), the temperature (and number of cores currently being used, as well as thier utilisation percent) affects the clock speed. Since CPUs are dynamically clocked, this can affect your results. For example, if you have a single-threaded application, the maximum clock speed (with TurboBoost) is higher than for an application using all cores. This can therefore interfere with comparisons of single and multi-threaded performance on some systems. Bear in mind that the temperature and volatages also affect how long Turbo frequency is maintained.



                                            Perhaps a more fundamentally important aspect that you have direct control over: make sure you're measuring the right thing! For example, if you're using System.nanoTime() to benchmark a particular bit of code, put the calls to the assignment in places that make sense to avoid measuring things which you aren't interested in. For example, don't do:



                                            long startTime = System.nanoTime();
                                            //code here...
                                            System.out.println("Code took "+(System.nanoTime()-startTime)+"nano seconds");


                                            Problem is you're not immediately getting the end time when the code has finished. Instead, try the following:



                                            final long endTime, startTime = System.nanoTime();
                                            //code here...
                                            endTime = System.nanoTime();
                                            System.out.println("Code took "+(endTime-startTime)+"nano seconds");





                                            share|improve this answer


























                                              5














                                              To add to the other excellent advice, I'd also be mindful of the following:



                                              For some CPUs (e.g. Intel Core i5 range with TurboBoost), the temperature (and number of cores currently being used, as well as thier utilisation percent) affects the clock speed. Since CPUs are dynamically clocked, this can affect your results. For example, if you have a single-threaded application, the maximum clock speed (with TurboBoost) is higher than for an application using all cores. This can therefore interfere with comparisons of single and multi-threaded performance on some systems. Bear in mind that the temperature and volatages also affect how long Turbo frequency is maintained.



                                              Perhaps a more fundamentally important aspect that you have direct control over: make sure you're measuring the right thing! For example, if you're using System.nanoTime() to benchmark a particular bit of code, put the calls to the assignment in places that make sense to avoid measuring things which you aren't interested in. For example, don't do:



                                              long startTime = System.nanoTime();
                                              //code here...
                                              System.out.println("Code took "+(System.nanoTime()-startTime)+"nano seconds");


                                              Problem is you're not immediately getting the end time when the code has finished. Instead, try the following:



                                              final long endTime, startTime = System.nanoTime();
                                              //code here...
                                              endTime = System.nanoTime();
                                              System.out.println("Code took "+(endTime-startTime)+"nano seconds");





                                              share|improve this answer
























                                                5












                                                5








                                                5






                                                To add to the other excellent advice, I'd also be mindful of the following:



                                                For some CPUs (e.g. Intel Core i5 range with TurboBoost), the temperature (and number of cores currently being used, as well as thier utilisation percent) affects the clock speed. Since CPUs are dynamically clocked, this can affect your results. For example, if you have a single-threaded application, the maximum clock speed (with TurboBoost) is higher than for an application using all cores. This can therefore interfere with comparisons of single and multi-threaded performance on some systems. Bear in mind that the temperature and volatages also affect how long Turbo frequency is maintained.



                                                Perhaps a more fundamentally important aspect that you have direct control over: make sure you're measuring the right thing! For example, if you're using System.nanoTime() to benchmark a particular bit of code, put the calls to the assignment in places that make sense to avoid measuring things which you aren't interested in. For example, don't do:



                                                long startTime = System.nanoTime();
                                                //code here...
                                                System.out.println("Code took "+(System.nanoTime()-startTime)+"nano seconds");


                                                Problem is you're not immediately getting the end time when the code has finished. Instead, try the following:



                                                final long endTime, startTime = System.nanoTime();
                                                //code here...
                                                endTime = System.nanoTime();
                                                System.out.println("Code took "+(endTime-startTime)+"nano seconds");





                                                share|improve this answer












                                                To add to the other excellent advice, I'd also be mindful of the following:



                                                For some CPUs (e.g. Intel Core i5 range with TurboBoost), the temperature (and number of cores currently being used, as well as thier utilisation percent) affects the clock speed. Since CPUs are dynamically clocked, this can affect your results. For example, if you have a single-threaded application, the maximum clock speed (with TurboBoost) is higher than for an application using all cores. This can therefore interfere with comparisons of single and multi-threaded performance on some systems. Bear in mind that the temperature and volatages also affect how long Turbo frequency is maintained.



                                                Perhaps a more fundamentally important aspect that you have direct control over: make sure you're measuring the right thing! For example, if you're using System.nanoTime() to benchmark a particular bit of code, put the calls to the assignment in places that make sense to avoid measuring things which you aren't interested in. For example, don't do:



                                                long startTime = System.nanoTime();
                                                //code here...
                                                System.out.println("Code took "+(System.nanoTime()-startTime)+"nano seconds");


                                                Problem is you're not immediately getting the end time when the code has finished. Instead, try the following:



                                                final long endTime, startTime = System.nanoTime();
                                                //code here...
                                                endTime = System.nanoTime();
                                                System.out.println("Code took "+(endTime-startTime)+"nano seconds");






                                                share|improve this answer












                                                share|improve this answer



                                                share|improve this answer










                                                answered Mar 19 '17 at 19:21









                                                Sina MadaniSina Madani

                                                5871719




                                                5871719

















                                                    protected by Will Feb 1 '11 at 14:07



                                                    Thank you for your interest in this question.
                                                    Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



                                                    Would you like to answer one of these unanswered questions instead?



                                                    這個網誌中的熱門文章

                                                    Academy of Television Arts & Sciences

                                                    L'Équipe

                                                    1995 France bombings