3

I wanted to know about differences in performance between arrays in c++ and java. I know that for object arrays in java, the objects are not stored contiguously in memory, only pointers to these objects are stored contiguously. What about for primitive types like ints? As far as I know the JVM doesn't guarantee that the array will be stored contiguously. I basically want to know what the main differences are in performance of primitive arrays between java and c++. Does bound checking also play a part in slowing arrays in java down?

henry14
  • 39
  • 1
  • What is the actual problem you're trying to solve? – NPE Oct 11 '14 at 07:46
  • I'm trying to build a very efficient circular buffer, so I'm trying to figure out if I should do it in c++ or Java – henry14 Oct 11 '14 at 07:49
  • Very efficient something = Asm. The nearest choice for you is C. – deviantfan Oct 11 '14 at 08:07
  • 2
    This has attracted a couple of close votes for being too broad. That is ridiculous IMO. It's a nicely written high level question, that allows for clear and well defined answers. Too much stomping around here. – chiastic-security Oct 11 '14 at 08:09

2 Answers2

1

As far as I know the JVM doesn't guarantee that the array will be stored contiguously.

While I don't see any cast-iron guarantee that the array elements will be stored contiguously, I believe they will for every mainstream implementation. And for primitive types, the primitive values are stored directly - not references. As far as I'm aware, all mainstream implementations pack the arrays too - so if you have a byte[] for example, it doesn't align each byte on a 4 or 8 byte boundary (thus multiplying the space required by 4 or 8). But a boolean[] value doesn't pack individual bits (in implementations I've used) - new boolean[n] takes the same space as new byte[n].

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
1

There are a few things to be aware of:

  1. An array of primitives is stored contiguously in Java, at least in a standard JVM. A multidimensional array is not necessarily contiguous, though: if you have an int[][] then each layer will be contiguous but two consecutive layers may not be. This has a performance overhead because looking up a value isn't a simple scale and add.
  2. Bound checking is essential to the JVM sandboxing, so there is nothing you can do to turn it off, and yes, it has a performance overhead.
  3. An array in Java is of constant size. It can't be resized later. If you want to resize it, you have to copy everything into a new array.
  4. There's no pointer arithmetic, so you can't pass a pointer to somewhere mid way through an array. This isn't really an issue: you pass the whole array, plus a value telling the method where to start processing. But it does sometimes make Java methods look a little different from their C counterparts.
  5. Arrays are always initialized in Java: each element is set to 0 or false or null (depending on type). This is because otherwise you would get undefined behaviour when you read from it before writing to it, and Java does all it can to avoid undefined behaviour. There is a performance overhead here too.

All that said, there are two things that make all this less problematic than you might think. For one, for your typical case of iterating over all elements in an array, you don't really encounter much problem. The bound is very simple, and might even get optimised away by the JIT compiler, which is very well tuned at optimising tight loops. And for another, by far the most important issue with heavy processing of arrays is asymptotic complexity, which is not affected by any of the above. So although Java is overall slower, you will still find that a bubble sort in C is much, much slower than a mergesort in Java.

One more key thing to note is that lots of this is there to help you and ensure safe coding. Of course it's possible to write rubbish in Java, but some sorts of rubbish are much easier to write in C: overshoot the end of an array and no one is going to stop you in your tracks.

chiastic-security
  • 20,430
  • 4
  • 39
  • 67
  • Note that 3. also applies to C and C++. There are functions like `realloc` that may succeed in "growing" an array without copying elements, but they aren't guaranteed to succeed in this. – juanchopanza Oct 11 '14 at 08:06
  • Another note to 3. Arrays cannot grow in size, I believe it is possible in Java to make arrays shrink, with some reflection magic, of course. – skiwi Oct 11 '14 at 15:31