<story><title>Quick Tips for Fast Code on the JVM</title><url>https://gist.github.com/djspiewak/464c11307cabc80171c90397d4ec34ef</url></story><parent_chain><item><author>barrkel</author><text>I&amp;#x27;d recommend a process rather than a handful of implementation-specific rules of thumb that are, IMO, at risk of being applied too generally. I&amp;#x27;d hate someone to read this article and then go ahead and avoid &amp;#x27;new&amp;#x27; wherever possible because they think that&amp;#x27;s how you make code fast, or avoiding boxing and polymorphic call sites, etc.&lt;p&gt;My process for writing fast code on the JVM:&lt;p&gt;1) Measure. Set up a benchmark so you know whether you&amp;#x27;re on the happy path or not, or whether you&amp;#x27;ve fallen off a performance cliff, for whatever reason. Make this part of your testing suite with some kind of notification for regressions.&lt;p&gt;2) Start small, ideally with a do-nothing loop over the input. This gives you a baseline; you can&amp;#x27;t go faster than a do-nothing loop (presuming you can&amp;#x27;t skip part of your input, which is an algorithm problem, not specific to JVM optimization).&lt;p&gt;3) Incrementally build up your algorithm and pay attention to when it falls off the performance cliff, using your benchmark from (1). If and when you fall off the performance cliff, that&amp;#x27;s when you start bringing in tricks like avoiding new, ensuring call sites are monomorphic &amp;#x2F; bimorphic, avoiding boxing, reducing pointer indirections and other cache friendly code, etc.&lt;p&gt;Another trick to consider is playing around with inlining, but not in the way you might think: try pushing infrequently executed code (conditionals) one level deeper in the call stack (i.e. making the body of an if-block into a method and calling it). The idea here is to encourage inlining of method doing the calling. Inlining is where the JVM gets to specialize your code to the specific situation at hand, but the JVM is reluctant to inline big methods because it has a time budget. So you need to help it.</text></item></parent_chain><comment><author>ballenarosada</author><text>I&amp;#x27;m a Java programmer who has tried and failed to do some optimizations this year following your general guidelines. I&amp;#x27;m extremely happy to finally see a piece of writing that expands my mental model of what is actually happening on the JVM. If we just keep repeating the same general truisms about measurement and inlining, then nobody will ever advance beyond my own low level of understanding.</text></comment>
<story><title>Quick Tips for Fast Code on the JVM</title><url>https://gist.github.com/djspiewak/464c11307cabc80171c90397d4ec34ef</url></story><parent_chain><item><author>barrkel</author><text>I&amp;#x27;d recommend a process rather than a handful of implementation-specific rules of thumb that are, IMO, at risk of being applied too generally. I&amp;#x27;d hate someone to read this article and then go ahead and avoid &amp;#x27;new&amp;#x27; wherever possible because they think that&amp;#x27;s how you make code fast, or avoiding boxing and polymorphic call sites, etc.&lt;p&gt;My process for writing fast code on the JVM:&lt;p&gt;1) Measure. Set up a benchmark so you know whether you&amp;#x27;re on the happy path or not, or whether you&amp;#x27;ve fallen off a performance cliff, for whatever reason. Make this part of your testing suite with some kind of notification for regressions.&lt;p&gt;2) Start small, ideally with a do-nothing loop over the input. This gives you a baseline; you can&amp;#x27;t go faster than a do-nothing loop (presuming you can&amp;#x27;t skip part of your input, which is an algorithm problem, not specific to JVM optimization).&lt;p&gt;3) Incrementally build up your algorithm and pay attention to when it falls off the performance cliff, using your benchmark from (1). If and when you fall off the performance cliff, that&amp;#x27;s when you start bringing in tricks like avoiding new, ensuring call sites are monomorphic &amp;#x2F; bimorphic, avoiding boxing, reducing pointer indirections and other cache friendly code, etc.&lt;p&gt;Another trick to consider is playing around with inlining, but not in the way you might think: try pushing infrequently executed code (conditionals) one level deeper in the call stack (i.e. making the body of an if-block into a method and calling it). The idea here is to encourage inlining of method doing the calling. Inlining is where the JVM gets to specialize your code to the specific situation at hand, but the JVM is reluctant to inline big methods because it has a time budget. So you need to help it.</text></item></parent_chain><comment><author>jnordwick</author><text>I&amp;#x27;m not really a fan of your &amp;quot;best practices&amp;quot;. Java often has unique problems where this generic advice breaks down (I do a lot of low latency and high performance work), and sometimes you need mechanism sympathy instead of relying on tools so much.&lt;p&gt;1- The author does tell you to understand your hot path. However in Java it is often difficult to pin down GC related issues and just easier to prevent them in the first place. I&amp;#x27;ve tried to go through code bases others have written top clean up allocation problems and they become so embedded in the code that it is easier to just rewrite. Or some issues like finalizer&amp;#x2F;weak ref issues are very difficult to find in your measurements.&lt;p&gt;2 and 3- I&amp;#x27;ve never seen this work. This is a great way to get a bunch of faulty analysis or not even know you&amp;#x27;re going off track to begin with.&lt;p&gt;This article and many of the tips are written when you are trying to be &amp;quot;as fast as possible&amp;quot; and where each microsecond counts. I&amp;#x27;ve seen a lot of projects go down in flames where they treated performance as something secondary the can be written into the code in a second pass. When you ate having to deal with issues like the article describes you should take a more first principles approach and keep your eye on the proper idioms inn the first place.</text></comment>