Q:

Questions of 'Designing for Performance' document at Android Developer site

In the Avoid Creating Objects section of the page Designing for Performance in the Android Developer documentation I read some paragraphs for which I am not able to visualize a code representation:
An array of ints is a much better than an array of Integers, but this also generalizes to the fact that two parallel arrays of ints are also a lot more efficient than an array of (int,int) objects. The same goes for any combination of primitive types.

How would these 'parallel arrays of ints' look like? Would it be something like instead of having a method with a signature such as getData():int[][] returning 

   [a][b]
   [c][d]
   [e][f]

... it would be better to have two methods, each returning one of the 'columns' of data? as in:
getFirstDimensionData():int[]

   [a]
   [c]
   [e]

and a second one getSecondDimensionData():int[]

   [b]
   [d]
   [f]

What is an 'array of (int,int) objects? ... something like an array of objects of a-type-not-yet-defined that has two int member instances defining its state?

The immediate next paragraph:
If you need to implement a container that stores tuples of (Foo,Bar) objects, try to remember that two parallel Foo[] and Bar[] arrays are generally much better than a single array of custom (Foo,Bar) objects.
... makes me think that the author is making up some sort of notation. I guess my key question is: is the author of the page using this (somethingX, somethingY) notation to refer to an arbitrary class that 'wraps' the elements inside the parentheses?
Finally, is this a standard notation or just something the author of the page created by himself and omitted to explain?
Can anyone, please, shed some light? :)
Thanks in advance,
Y

A:

What they're saying is that
class foo {
    int a;
    int b;
}

foo[] bar;

Is slower than
int[] foo;

With foo[row*2] being a and foo[row*2+1] being b.
The notation (foo, bar) is trying to symbolize a class that contains foo and bar (like (a,b) in my above example).
I don't believe it's a standard notation, but it wouldn't be the first time I've been proven wrong.

