Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Getter performance Date: Sun, 16 Oct 2011 09:47:05 -0400 Organization: A noiseless patient Spider Lines: 67 Message-ID: References: <4e99f537$0$623$426a74cc@news.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 16 Oct 2011 13:47:41 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="f8igmItKsWs6nM5YanFxAA"; logging-data="27832"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19rMukjgx/RJxvfC5gpmUy2" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 In-Reply-To: <4e99f537$0$623$426a74cc@news.free.fr> Cancel-Lock: sha1:dOgBl3aCbGMlnT8dUHisWTLG/84= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8861 On 10/15/2011 5:03 PM, Aéris wrote: > > I work on an application where performances are important. > > To optimize it, I thought a direct access to a variable (foo.bar) would > be more efficient than a getter call (foo.getBar()). > I thought by avoiding the call to a method and all that goes with it > (context switching, stacking, return value…), I can save time, but this > code sample prove the contrary : > http://pastebin.com/bP1nqxce > Direct variable access : 1041 ms > Getter call : 556 ms > > The difference is even more important if I don't modify the variable > value (lines 29 and 36 commented) : > Direct variable access : 95 ms > Getter call : 4 ms > > How can we explain this not obvious huge difference ( 50 and 95% ) ? Insufficiently precise measurement. You are trying to tell whether two nickels are heavier than four pennies by piling each stack of coins in turn atop a bulldozer and weighing the bulldozer. If you want to measure tiny effects, seek a measurement framework that doesn't involve huge effects. Fundamentally, though, you're going about the larger task in the wrong way: You are simply guessing that the speed of access to a variable is important to the performance of your application. Do you have even the slightest shred of evidence that this is so? Or are you trying to improve your car's fuel economy by scraping off all the paint to reduce the vehicle weight? 1: Decide what performance criteria the application must satisfy. Make this quantifiable: "Throughput of at least X doodads per eyeblink" or "95% of responses in no more than Y milliquivers," not undecidable like "As fast as possible." 2: (Optional) Make back-of-the-envelope calculations about data rates, data set sizes, and so on, just to estimate the resources that will be required. Is the load within reach of a laptop, or do you need a clustered network of supercomputers? Can you handle the traffic with WiFi, or do you need sixteen 10Gb/s fibers in parallel? 3: Write the application, as cleanly and simply as you can in light of [1] and [2]. During this stage, bear in mind that even the most expert of programmers is usually surprised about where his code spends the majority of its time (this is not opinion; it's been found over and over again in actual experiment). In other words, favor "clean and simple" over "clever and reputedly fast." 4: Measure the performance, and compare to the thresholds of [1]. If you satisfy [1], stop! 5: (Only if [1] isn't satisfied) Apply profilers, debuggers, and other tools to discover which parts of the program are too slow. Apply your efforts to speeding up those parts only; pay no attention to the others. Then return to [4]. In very rare cases (usually when [2] was skipped or when some external agency forces a change in [1]), return to [3] and start over. Do not begin by trying to micro-optimize; that way lies madness. Trust me; I know: Been there, done that, bear the scars. -- Eric Sosman esosman@ieee-dot-org.invalid