3

I tried to measure execution time of primitive data types and their wrapper class for counting same number. I got that wrapper class is taking more time than primitive data types.

Execution time of primitive t1=5 and Execution time of wrapper class t2= 31 in my following code.

import java.io.*;
import java.util.*;
public class Performance
{
  public static long primitive(int count)
     {
   long startTime = System.currentTimeMillis();
   for(int i=0;i<10000;i++)
     count++;
    System.out.println(count);
   long stopTime = System.currentTimeMillis();
   long elapsedTime = stopTime - startTime;
   return elapsedTime;
}
  public static long wrapper(Integer count)
{
    long startTime = System.currentTimeMillis();
    for(int i=0;i<10000;i++)
      count++;
      System.out.println(count);
    long stopTime = System.currentTimeMillis();
    long elapsedTime = stopTime - startTime;
    return elapsedTime;
 }

  public static void main(String args[])
  {

   Integer c = new Integer(0);
   long t2=Performance.wrapper(c);
    int count=0;
   long t1=Performance.primitive(count);
  System.out.println("t1="+t1+"t2="+t2);

  }
}

Is there performance difference due to object creation of Wrapper class (Integer) or anything else ?

GhostCat
  • 137,827
  • 25
  • 176
  • 248
Shree Prakash
  • 2,052
  • 2
  • 22
  • 33
  • Instead of creating the wrapper yourself, try using casting/autoboxing. `Integer` is cached within the byte range. Regardless, your method for microbenchmarking isn't quite up to par with what you need for accurate results (jvm warmup, way more runs, nano vs millis, etc) – Rogue Nov 01 '16 at 19:36
  • You could also try flipping the processing order to try your wrapper before the primitive to see if you see the same thing. I agree with Rogue though - there are some issues with the micro benchmarking you're doing. Take a look at https://github.com/google/caliper if you want more detail into the reasons. – Snekse Nov 01 '16 at 19:41
  • You might want to update with question with _why_ you care. You might get better answers. – Snekse Nov 01 '16 at 19:42
  • @Snekse Sir thanks a lot. When I flipped the processing order of wrapper before the primitive . I got same. – Shree Prakash Nov 01 '16 at 19:58
  • And you measure the time to output of 'count'. You should move the System.out behind the 'stopTime'. IO operations may influence the result notable. – Konrad Nov 01 '16 at 20:47

1 Answers1

13

You are getting essential things wrong here.

First of all, writing a good micro-benchmark goes way beyond what you are doing in your code; see here for some guidelines.

Then: you have to understand the things you want to benchmark. For example:

public static long wrapper(Integer count)
{
  long startTime = System.currentTimeMillis();
  for(int i=0;i<10000;i++)
    count++

Integer objects are immutable. This code does not only "add" Integer objects, it creates one new Integer object per iteration.

And of course: your code doesn't even use the computation result. If the JVM/JIT notices that, it might completely throw away that looping and adding construct. So your methods should at least return the final value of count; and the caller should print that result.

And to answer your specific question: of course using the reference type wrapper classes comes at certain cost. When your program is dealing with (really) high numbers of elements to work on, then using a List of Integer does have considerable higher cost than using an array of int for example. And when you don't pay attention and you are doing implicit autoboxing/unboxing in your code, that can really hurt.

But the real answer here is: you are focusing on the wrong thing. You see, your first priority should be to do a great design, followed by a well-tested, robust, readable, maintainble implementation. Of course, you should not do outright stupid things and waste performance, but well, before you worry about performance, you better worry about your Java skills in general.

Long story short: focus on understanding java and on "how do I create a good design"; and forget about "performance" for now. You only have to deal with "performance" when it is a real issue in your application. And then you do real profiling in order to identify the root cause and fix that.

3pitt
  • 899
  • 13
  • 21
GhostCat
  • 137,827
  • 25
  • 176
  • 248