Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #36909

Re: A third easy performance optimisation needed

Show all headers | View raw

On 7/13/17 8:41 AM, Cecil Westerhof wrote:
> And it also shows that using a long where an integer is sufficient it
> can have a gigantic difference. On my system the long/integer (which
> already takes a third less time in the first run) is after 5 runs
> about  2½ million times faster as after the first run, while the
> long/long part is not optimised. See my reply in:
>      One code is aggressively optimised, while another not. Why?

If you're going to give a talk on performance optimization, you're 
already wildly off course from the starting foot.

The first thing about performance optimization is knowing how to measure 
performance accurately. There are a lot of bad ways to do it, and it's 
actually quite hard to do it accurately. Microbenchmarks--where you're 
trying to assess the impact of tiny snippets of code rather than entire 
applications--are even more difficult to measure accurately, and that's 
even before you take into account the difficulty of a JIT.

I mentioned earlier in the other thread that I'm skeptical of your 
testing framework, and when I saw the code, it's clear to me that said 
skepticism is well-warranted--your testing code is not going to be 
reflective of anything.

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.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

A third easy performance optimisation needed Cecil Westerhof <Cecil@decebal.nl> - 2017-07-13 09:54 +0200
  Re:A third easy performance optimisation needed omegajunior <omegajunior@protonmail.com> - 2017-07-13 06:29 -0400
  Re: A third easy performance optimisation needed Martin Gregorie <martin@address-in-sig.invalid> - 2017-07-13 11:27 +0000
  Re: A third easy performance optimisation needed Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-13 07:41 -0400
    Re: A third easy performance optimisation needed Eric Douglas <e.d.programmer@gmail.com> - 2017-07-13 05:48 -0700
      Re: A third easy performance optimisation needed Arne Vajhøj <arne@vajhoej.dk> - 2017-07-13 19:39 -0400
    Re: A third easy performance optimisation needed Cecil Westerhof <Cecil@decebal.nl> - 2017-07-13 15:14 +0200
      Re: A third easy performance optimisation needed Eric Douglas <e.d.programmer@gmail.com> - 2017-07-13 07:07 -0700
        Re: A third easy performance optimisation needed Robert Klemme <shortcutter@googlemail.com> - 2017-07-13 19:58 +0200
          Re: A third easy performance optimisation needed Cecil Westerhof <Cecil@decebal.nl> - 2017-07-13 20:02 +0200
  Re: A third easy performance optimisation needed Arne Vajhøj <arne@vajhoej.dk> - 2017-07-13 08:16 -0400
    Re: A third easy performance optimisation needed Eric Douglas <e.d.programmer@gmail.com> - 2017-07-13 06:08 -0700
      Re: A third easy performance optimisation needed Cecil Westerhof <Cecil@decebal.nl> - 2017-07-13 15:41 +0200
        Re: A third easy performance optimisation needed Eric Douglas <e.d.programmer@gmail.com> - 2017-07-13 07:09 -0700
          Re: A third easy performance optimisation needed Eric Douglas <e.d.programmer@gmail.com> - 2017-07-13 08:07 -0700
          Re: A third easy performance optimisation needed Cecil Westerhof <Cecil@decebal.nl> - 2017-07-13 18:37 +0200
        Re: A third easy performance optimisation needed Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2017-07-13 13:19 -0500
          Re: A third easy performance optimisation needed Arne Vajhøj <arne@vajhoej.dk> - 2017-07-13 14:32 -0400
      Re: A third easy performance optimisation needed Arne Vajhøj <arne@vajhoej.dk> - 2017-07-13 13:52 -0400
        Re: A third easy performance optimisation needed Eric Douglas <e.d.programmer@gmail.com> - 2017-07-14 07:52 -0700
  A third easy performance optimisation needed lewbloch@gmail.com - 2017-07-14 14:47 -0700

csiph-web