Path: csiph.com!aioe.org!.POSTED!not-for-mail From: =?UTF-8?Q?Arne_Vajh=c3=b8j?= Newsgroups: comp.lang.java.programmer Subject: Re: A third easy performance optimisation needed Date: Thu, 13 Jul 2017 14:32:11 -0400 Organization: Aioe.org NNTP Server Lines: 39 Message-ID: References: <87d1946ab3.fsf@munus.decebal.nl> <87pod44foe.fsf@munus.decebal.nl> NNTP-Posting-Host: PBuS014lhzVyHjLbXmo/ZQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.java.programmer:36910 On 7/13/2017 2:19 PM, Joshua Cranmer 🐧 wrote: > Before you do anything else, please start by using a proper Java > microbenchmarking harness (hint: if you're writing it yourself, it's not > a proper harness). > > Rather, if you're trying to give a presentation on performance > optimizations, here's the rules you should be presenting instead: > > 1. Ignore all advice on performance optimization that says "use X > instead of Y" or "avoid X." That's not to say it's all wrong, but much > of it is based on incorrect preconceptions or poorly-conducted studies. > At best, this sort of advice should generally be thought of as places to > start looking for performance improvements when you've identified problems. > > 2. Learn how to measure performance properly (indeed, on any of this > kind of presentation, this should be the brunt of the presentation). In > particular, performance needs to be measured holistically, testing as > much of the system as possible. And evaluating performance improvements > needs to also avoid the pitfall of "we tuned the GC to not run on our > benchmark, fixing all performance issues!" > > 2a. In particular, say no to microbenchmarks. They have their uses. But > their applicability is often minimal, far less than many people look for > in a benchmark. If you don't have the resources to be able to explain > why the optimizer is preferring differences (e.g., you're not reading > the assembly), then you likely don't have the ability to understand the > applicability, much less communicate the results properly. > > 3. Performance optimization is a step that only happens once you've > measured and identified the bottlenecks. If you don't have the results > saying "this part right here is the problem," you're not ready yet. Goetz has also written about microbenchmarks: https://www.ibm.com/developerworks/java/library/j-jtp02225/ Arne