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

Groups > comp.lang.java.programmer > #36875 > unrolled thread

A third easy performance optimisation needed

Back to article view | Back to comp.lang.java.programmer

Contents

  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

Page 1 of 2  [1] 2  Next page →

#36875 — A third easy performance optimisation needed

I am going to give a presentation about how to easily improve the
performance of your Java programs. Two subjects I already have are
using final and being careful with autoboxing. I would like a third
one. Anyone a good suggestion?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]

#36879

Cecil Westerhof <Cecil@decebal.nl> Wrote in message:
> I am going to give a presentation about how to easily improve the
> performance of your Java programs. Two subjects I already have are
> using final and being careful with autoboxing. I would like a third
> one. Anyone a good suggestion?
> 
> -- 
> Cecil Westerhof
> Senior Software Engineer
> LinkedIn: http://www.linkedin.com/in/cecilwesterhof
> 

Synchronisation and locking in multithreaded environments; 
  
Batching file and data store operarions rather than opening new
 connections for every record; 
 
Horizontal scaling by running multiple copies of an application
 simultaneously. 
-- 
We make software faster. What can you do with gained free time?


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[toc] | [prev] | [next] | [standalone]

#36880

On Thu, 13 Jul 2017 09:54:56 +0200, Cecil Westerhof wrote:

> I am going to give a presentation about how to easily improve the
> performance of your Java programs. Two subjects I already have are using
> final and being careful with autoboxing. I would like a third one.
> Anyone a good suggestion?

If you need both keyed random access and sequential access to a medium to 
large collection of objects, use a TreeMap rather than loading the data 
into flat structure (ArrayList) and sorting it because:

- a TreeMap efficiently inserts objects in key sequence

- walking a TreeMap is quite an efficient way of visiting objects 
  in key sequence

- keyed retrieval becomes progressively more efficient as the collection
  size grows. If the collection contains 2^n items, you only need n key
  comparisons to find a given key, so 4 comparisons if the tree holds 16
  items but only 23 comparisons if it holds 8 million items.
    
This is because TreeMap is implemented as a red-black binary tree. This 
is a self-balancing tree structure. See Sedgewick: "Algorithms" for a 
discussion of how it works.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#36882

On 7/13/2017 3:54 AM, Cecil Westerhof wrote:
> I am going to give a presentation about how to easily improve the
> performance of your Java programs. Two subjects I already have are
> using final and being careful with autoboxing. I would like a third
> one. Anyone a good suggestion?

     I'm not sure what you intend to say about `final', but I
hope you're familiar with Brian Goetz' thoughts on the matter:

https://www.ibm.com/developerworks/java/library/j-jtp04223/index.html#N10087

https://www.ibm.com/developerworks/java/library/j-jtp1029/index.html

-- 
esosman@comcast-dot-net.invalid
Twelve hundred eighty-seven days to go.

[toc] | [prev] | [next] | [standalone]

#36885

On Thursday, July 13, 2017 at 7:41:39 AM UTC-4, Eric Sosman wrote:
>      I'm not sure what you intend to say about `final', but I
> hope you're familiar with Brian Goetz' thoughts on the matter:
> 
> https://www.ibm.com/developerworks/java/library/j-jtp04223/index.html#N10087
> 
> https://www.ibm.com/developerworks/java/library/j-jtp1029/index.html

So final classes and methods may not improve performance or definitely won't improve performance?  Even if they do improve performance, if the improvement is insignificant it is a valid point you should not do it unless you definitely don't want the class extended or method overridden.  Oracle does use it occasionally for that reason, notably in the String class.

So final variables don't affect performance either way?  I do use the Eclipse option to automatically declare variables final which are assigned exactly once.  As long as that won't hurt performance it seems a good thing.

These articles were written in 2002-3.  I wonder if it's all still relevant.  I thought the code snippet seemed odd.

// Immutable -- returns an unmodifiable List instead
public class SafeStates {
  private final String[] states = new String[] { "Alabama", "Alaska", ... };
  private final List statesAsList 
    = new AbstractList() {
        public Object get(int n) { 
          return states[n];
        }
 
        public int size() {
          return states.length;
        }
      };
         
  public List getStates() {
    return statesAsList;
  }
}

Why not use Oracle's method?
http://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#unmodifiableList-java.util.List-

[toc] | [prev] | [next] | [standalone]

#36921

On 7/13/2017 8:48 AM, Eric Douglas wrote:
> On Thursday, July 13, 2017 at 7:41:39 AM UTC-4, Eric Sosman wrote:
>>       I'm not sure what you intend to say about `final', but I
>> hope you're familiar with Brian Goetz' thoughts on the matter:
>>
>> https://www.ibm.com/developerworks/java/library/j-jtp04223/index.html#N10087
>>
>> https://www.ibm.com/developerworks/java/library/j-jtp1029/index.html
> 
> So final classes and methods may not improve performance or definitely won't improve performance?

I think the conclusion is that there is no reason to expect a
performance improvement.

The actual performance may vary between Java vendor (Oracle, IBM,
Azul etc.), version and platform.

> Even if they do improve performance, if the improvement is insignificant it is a valid point
> you should not do it unless you definitely don't want the class extended or method overridden.
> Oracle does use it occasionally for that reason, notably in the String class.

There are good reasons to use final. Good reasons relating to the OO
design.

> So final variables don't affect performance either way?

Not sure. I am not a JVM expert like Goetz. My guess would be that
it is the same: no reason to expect a big performance difference,
but other reasons within design exist.

> I do use the Eclipse option to automatically declare variables
> final which are assigned exactly once.

That is an increasingly popular trend.

> These articles were written in 2002-3.  I wonder if it's all still relevant.

The JIT compilers optimizer has become even smarter than it was in 2003.

The smarter the optimizer is the dum,ber it is to try and manual
optimize the code.

Arne

[toc] | [prev] | [next] | [standalone]

#36887

Eric Sosman <esosman@comcast-dot-net.invalid> writes:

> On 7/13/2017 3:54 AM, Cecil Westerhof wrote:
>> I am going to give a presentation about how to easily improve the
>> performance of your Java programs. Two subjects I already have are
>> using final and being careful with autoboxing. I would like a third
>> one. Anyone a good suggestion?
>
>     I'm not sure what you intend to say about `final', but I
> hope you're familiar with Brian Goetz' thoughts on the matter:
>
> https://www.ibm.com/developerworks/java/library/j-jtp04223/index.html#N10087
>
> https://www.ibm.com/developerworks/java/library/j-jtp1029/index.html

As said there: for class and methods it can be wrong, but I am talking
about variables. And there it can make a difference. I one case code
takes 3 minutes without final and 18 seconds with final. That is
almost 17 times as fast.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#36890

On Thursday, July 13, 2017 at 9:28:19 AM UTC-4, Cecil Westerhof wrote:
> As said there: for class and methods it can be wrong, but I am talking
> about variables. And there it can make a difference. I one case code
> takes 3 minutes without final and 18 seconds with final. That is
> almost 17 times as fast.
> 

I would like to see the performance tests on that.

[toc] | [prev] | [next] | [standalone]

#36905

On 13.07.2017 16:07, Eric Douglas wrote:
> On Thursday, July 13, 2017 at 9:28:19 AM UTC-4, Cecil Westerhof wrote:
>> As said there: for class and methods it can be wrong, but I am talking
>> about variables. And there it can make a difference. I one case code
>> takes 3 minutes without final and 18 seconds with final. That is
>> almost 17 times as fast.
> 
> I would like to see the performance tests on that.

Same here.  And frankly, I doubt that declaration of final for a 
variable can make this difference - especially since in Java 8 some 
automatic final detection is done anyway.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#36908

Robert Klemme <shortcutter@googlemail.com> writes:

> On 13.07.2017 16:07, Eric Douglas wrote:
>> On Thursday, July 13, 2017 at 9:28:19 AM UTC-4, Cecil Westerhof wrote:
>>> As said there: for class and methods it can be wrong, but I am talking
>>> about variables. And there it can make a difference. I one case code
>>> takes 3 minutes without final and 18 seconds with final. That is
>>> almost 17 times as fast.
>>
>> I would like to see the performance tests on that.
>
> Same here.  And frankly, I doubt that declaration of final for a
> variable can make this difference - especially since in Java 8 some
> automatic final detection is done anyway.

I will post something this weekend.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#36884

On 7/13/2017 3:54 AM, Cecil Westerhof wrote:
> I am going to give a presentation about how to easily improve the
> performance of your Java programs. Two subjects I already have are
> using final and being careful with autoboxing. I would like a third
> one. Anyone a good suggestion?

Drop the two items you already have??

:-)

Seriously I don't think using final and avoiding auto-boxing
are good performance topics.

I would not expect any impact in overall performance of real world
applications.

Arne

[toc] | [prev] | [next] | [standalone]

#36886

On Thursday, July 13, 2017 at 8:16:38 AM UTC-4, Arne Vajhøj wrote:
> 
> Drop the two items you already have??
> 
> :-)
> 
> Seriously I don't think using final and avoiding auto-boxing
> are good performance topics.
> 
> I would not expect any impact in overall performance of real world
> applications.
> 
> Arne

Since my compiler doesn't warn, I don't pay much attention to implicit autoboxing.  I don't know why anyone would do unnecessary explicit autoboxing.  I'd like to see a real world sample showing notable performance improvement by going out of your way to avoid autoboxing.  Often using it does at least make code more readable.

[toc] | [prev] | [next] | [standalone]

#36889

Eric Douglas <e.d.programmer@gmail.com> writes:

> On Thursday, July 13, 2017 at 8:16:38 AM UTC-4, Arne Vajhøj wrote:
>> 
>> Drop the two items you already have??
>> 
>> :-)
>> 
>> Seriously I don't think using final and avoiding auto-boxing
>> are good performance topics.
>> 
>> I would not expect any impact in overall performance of real world
>> applications.
>> 
>> Arne
>
> Since my compiler doesn't warn, I don't pay much attention to implicit
> autoboxing. I don't know why anyone would do unnecessary explicit
> autoboxing. I'd like to see a real world sample showing notable
> performance improvement by going out of your way to avoid autoboxing.
> Often using it does at least make code more readable.

Look at the example at:
    https://github.com/CecilWesterhof/JavaExamples/blob/master/BoxedTest.java

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?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#36891

On Thursday, July 13, 2017 at 9:44:17 AM UTC-4, Cecil Westerhof wrote:
> 
> Look at the example at:
>     https://github.com/CecilWesterhof/JavaExamples/blob/master/BoxedTest.java
> 
> 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?
>

I could be wrong but it looks to me that your test code here is significantly flawed.  It was brought up in that other thread that the test was flawed.

If you're testing something 5 times you're not getting a real world sample.  Depending how long each iteration takes I would run 1,000 if not 1,000,000.

[toc] | [prev] | [next] | [standalone]

#36896

On Thursday, July 13, 2017 at 10:10:06 AM UTC-4, Eric Douglas wrote:
> 
> I could be wrong but it looks to me that your test code here is significantly flawed.  It was brought up in that other thread that the test was flawed.
> 

So here's a good example of flawed testing.  Eric S posted a link to a blog about finals.  Someone in the comments section posted a sample they claim is proof that code runs faster with variables declared as final.
I pasted their text into Eclipse, added a zero to iterations to get a better sample size, and hit run.

Test 1)

public class FinalTest {

public static final int N_ITERATIONS = 100000000;

public static String testNonFinal() {
String a = "a";
String b = "b";
return a + b;
}

public static String testFinal() {
final String a = "a";
final String b = "b";
return a + b;
}

public static void main(String[] args) {
long tStart;

tStart = System.currentTimeMillis();
for (int i = 0; i < N_ITERATIONS; i++)
testFinal();
System.out.println("Method with finals took " + (System.currentTimeMillis() - tStart) + " ms");

tStart = System.currentTimeMillis();
for (int i = 0; i < N_ITERATIONS; i++)
testNonFinal();
System.out.println("Method without finals took " + (System.currentTimeMillis() - tStart) + " ms");
}
}

Result: It claims the non-final method takes 500-540 ms and the final method takes 0-16 ms.

Test 2: I reverse the order to see if that mattered on optimization.


public static void main(String[] args) {
long tStart;

tStart = System.currentTimeMillis();
for (int i = 0; i < N_ITERATIONS; i++)
testNonFinal();
System.out.println("Method without finals took " + (System.currentTimeMillis() - tStart) + " ms");

tStart = System.currentTimeMillis();
for (int i = 0; i < N_ITERATIONS; i++)
testFinal();
System.out.println("Method with finals took " + (System.currentTimeMillis() - tStart) + " ms");
}
}

Result: It claims a method with final variables takes 0-16 ms and the same method without finals takes 500-540 ms.

Test 3: I move a variable outside the limited little method.

public class FinalTest {

public static final int N_ITERATIONS = 100000000;

public static String testNonFinal(String a) {
String b = "b";
return a + b;
}

public static String testFinal(final String a) {
final String b = "b";
return a + b;
}

public static void main(String[] args) {
long tStart;

tStart = System.currentTimeMillis();
for (int i = 0; i < N_ITERATIONS; i++)
testNonFinal("a");
System.out.println("Method without finals took " + (System.currentTimeMillis() - tStart) + " ms");

tStart = System.currentTimeMillis();
for (int i = 0; i < N_ITERATIONS; i++)
testFinal("a");
System.out.println("Method with finals took " + (System.currentTimeMillis() - tStart) + " ms");
}
}

Result: It claims this method takes around 430 ms with finals, or around 3300 without.

Test 4: I reverse the order.


public static void main(String[] args) {
long tStart;

tStart = System.currentTimeMillis();
for (int i = 0; i < N_ITERATIONS; i++)
testFinal("a");
System.out.println("Method with finals took " + (System.currentTimeMillis() - tStart) + " ms");

tStart = System.currentTimeMillis();
for (int i = 0; i < N_ITERATIONS; i++)
testNonFinal("a");
System.out.println("Method without finals took " + (System.currentTimeMillis() - tStart) + " ms");
}
}

Now it claims the method takes around 3300 ms with finals, around 430 ms without finals.  I changed the passed in value from "a" to a final variable, same result.

Conclusion: Tests can be deceiving.  Make sure you've tested every angle before you preach something as fact.  If you think something makes your code faster, does it make all code faster?  Why does it seem faster?

[toc] | [prev] | [next] | [standalone]

#36899

Eric Douglas <e.d.programmer@gmail.com> writes:

> On Thursday, July 13, 2017 at 9:44:17 AM UTC-4, Cecil Westerhof wrote:
>> 
>> Look at the example at:
>>     https://github.com/CecilWesterhof/JavaExamples/blob/master/BoxedTest.java
>> 
>> 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?
>>
>
> I could be wrong but it looks to me that your test code here is significantly flawed.  It was brought up in that other thread that the test was flawed.
>
> If you're testing something 5 times you're not getting a real world sample.  Depending how long each iteration takes I would run 1,000 if not 1,000,000.

OK, I changed the code. I still repeat it five times, but I now have
an inner loop that repeats it 100_000_000 times. I still see
significant differences:
    17:43:40: Timing long int    
    17:43:40: took 1.57E-02 seconds.
    17:43:40: took 1.33E-01 seconds.
    17:43:41: took 1.24E-01 seconds.
    17:43:41: took 1.24E-01 seconds.
    17:43:41: took 1.24E-01 seconds.

    17:43:41: Timing long long   
    17:43:41: took 1.04E+01 seconds.
    17:43:51: took 1.05E+01 seconds.
    17:44:02: took 1.04E+01 seconds.
    17:44:12: took 1.04E+01 seconds.
    17:44:23: took 1.04E+01 seconds.

    17:44:33: Timing Long int    
    17:44:33: took 7.31E+01 seconds.
    17:45:46: took 7.64E+01 seconds.
    17:47:03: took 8.02E+01 seconds.
    17:48:23: took 7.38E+01 seconds.
    17:49:37: took 8.38E+01 seconds.

    17:51:00: Timing Long long   
    17:51:00: took 8.51E+01 seconds.
    17:52:26: took 8.47E+01 seconds.
    17:53:50: took 8.41E+01 seconds.
    17:55:14: took 8.44E+01 seconds.
    17:56:39: took 8.43E+01 seconds.

    17:58:03: Timing long Integer
    17:58:03: took 3.44E+01 seconds.
    17:58:37: took 3.44E+01 seconds.
    17:59:12: took 3.44E+01 seconds.
    17:59:46: took 3.48E+01 seconds.
    18:00:21: took 3.44E+01 seconds.

    18:00:55: Timing long Long   
    18:00:55: took 4.21E+01 seconds.
    18:01:38: took 4.26E+01 seconds.
    18:02:20: took 4.23E+01 seconds.
    18:03:02: took 4.22E+01 seconds.
    18:03:45: took 4.25E+01 seconds.

    18:04:27: Timing Long Integer
    18:04:27: took 9.11E+01 seconds.
    18:05:58: took 8.99E+01 seconds.
    18:07:28: took 8.99E+01 seconds.
    18:08:58: took 9.00E+01 seconds.
    18:10:28: took 8.96E+01 seconds.

    18:11:58: Timing Long Long   
    18:11:58: took 9.59E+01 seconds.
    18:13:34: took 9.63E+01 seconds.
    18:15:10: took 9.55E+01 seconds.
    18:16:45: took 9.53E+01 seconds.
    18:18:21: took 9.54E+01 seconds.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#36909

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

[toc] | [prev] | [next] | [standalone]

#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

[toc] | [prev] | [next] | [standalone]

#36904

On 7/13/2017 9:08 AM, Eric Douglas wrote:
> On Thursday, July 13, 2017 at 8:16:38 AM UTC-4, Arne Vajhøj wrote:
>> Seriously I don't think using final and avoiding auto-boxing
>> are good performance topics.
>>
>> I would not expect any impact in overall performance of real world
>> applications.
> 
> Since my compiler doesn't warn, I don't pay much attention to
> implicit autoboxing. I don't know why anyone would do unnecessary explicit
> autoboxing.

I just said auto-boxing including both explicit and implicit.

And  no need for explicit since 1.5.

>        I'd like to see a real world sample showing notable
> performance improvement by going out of your way to avoid autoboxing.

That was sort of my point.

But examples can probably be constructed showing a difference.

I would expect a big difference between ArrayList<ArrayList<Double>> and
double[][] for very compute intensive usage.

But not the usual business application.

Arne

[toc] | [prev] | [next] | [standalone]

#36928

On Thursday, July 13, 2017 at 1:53:07 PM UTC-4, Arne Vajhøj wrote:
> I just said auto-boxing including both explicit and implicit.
> 
> And  no need for explicit since 1.5.
> 
> >        I'd like to see a real world sample showing notable
> > performance improvement by going out of your way to avoid autoboxing.
> 
> That was sort of my point.
> 
> But examples can probably be constructed showing a difference.
> 
> I would expect a big difference between ArrayList<ArrayList<Double>> and
> double[][] for very compute intensive usage.
> 
> But not the usual business application.
> 
> Arne

Most if not all autoboxing can now be done implicitly, though the compiler doesn't complain about explicit autoboxing, and there's probably still plenty of that in old code.

          int i1 = 1;
          Integer i2 = new Integer(i1);
          i1 = i2.intValue();

Does i3 take more memory than i4?  Does i4 run faster?

          Integer[] i3 = new Integer[] {1,2};
          int[] i4 = new int[] {1,2};

int is still not quite the same as Integer, so even if int is preferred, sometimes Integer is required.
I have one case where I wanted an int[] to store values but I used an Integer[] because I wanted to populate it from a List.

          ArrayList<Integer> ar = new ArrayList();
          ar.add(1);
          ar.add(2);
          ar.add(3);
          Integer[] arVals = new Integer[ar.size()];
          ar.toArray(arVals);

This implicit conversion may be helpful and confusing.  Say I have a method:

     public static void testMethod(Object o) {
          System.out.println("object");
     }

I call the method, testMethod(5), it prints "object".
Now I overload the method:

     public static void testMethod(int i) {
          System.out.println("primitive");
     }

That same call, testMethod(5), now prints "primitive".
I would guess it's still good practice to declare variables as primitives wherever possible, but what exactly is meant by "being careful with autoboxing"?  Unless it can be proven that referencing them as objects is using notably more memory or time I wouldn't consider it a worthwhile performance topic.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web