I think Sinan's response hilights a number of issues and misunderstandings about Java and/or general programming.

Before getting bogged down in the details, I should make a statement about the notion that optimisation (for speed, code size, etc) should be one of the last things to consider when writing code. Especially in a learning-to-program sort of environment. I'm not (yet) a great Object-Oriented coder, but I do lament at seeing a lot of decidedly non-OO, awkward and inelegant code, especially when it seems to be through a lack of understanding and/or misguided instruction.

Sinan is the creator of the OpenProcessing site, and take that as experience enough to not be considered a newbie! However, there are some vague and also some incorrect notions about what is going on.

The OSC Media Controller code example defines a Button class, starting as follows:
Code:

class Button { 
 
  // general variables used accross class 
  final int x = 0; final int y = 1;                                      // variables to use with matrix size array 
  // ...
  // matrix and cell related variables 
  float [] buttonSize = new float [2];                                   // width and height of each button        
  float [] buttonLoc = new float [2];                                    // location of the button 
  float [] relativeMouseLoc = new float [2];                             // holds relative location of mouse on object (0,0 being top left hand corner) 
  // ...
 // define the button class constructor 
 Button(int tXloc, int tYloc, int twidth, int theight) { 
  buttonLoc[x] = tXloc; 
  buttonLoc[y] = tYloc; 
  buttonSize[x] = twidth; 
  buttonSize[y] = theight; 
 }  
 

My immediate reaction upon seeing "final int x = 0; final int y = 1;" was to think that was a bit strange. x and y are universally understood in many contexts to refer to some sort of position or vector, but here they are used as constant array indices.

Sinan suggests that "buttonLoc[0]" is fastest, and that "buttonLoc[x]" is "slower, since it is a dictionary". Firstly, since x is a constant ("final int"), I expect that it should be, or has the potential to be, exactly the same as using the literal constant 0 (by that I mean a compiler could produce the exact same executable code regardless of whether "x" or "0" are used, excusing cases where different variable types cause confusion). If x was not constant (that is, not "final"), then I agree there is another lookup required to find what the current value of x is each time, but I think Sinan is confusing the issue with thinking it is like using buttonLoc["x"] in PHP or something, where the "x" is not an integer variable but rather a  dictionary key to look up in an associative array (which is, of course, far more compute intensive).

I also disagree that using buttonLoc[0] and buttonLoc[1] should be slower than using separate fields buttonLocX and buttonLocY; indeed I expect the latter to have faster access.

Resoning:

buttonLoc[0] requires the location of the field (the buttonLoc array) and an array index, which is not only a number, but (probably) a number that needs to be multiplied by another number (the size of an individual array element) to get the actual memory offset.

buttonLocX requires only the location of the field.

I should mention that, in both cases, the "location of the field" is itself an offset from the object's base location. How memory addresses are determined in Java is a somewhat unknown to me; my description here relates to the way things usually work for C or C++ structs and arrays.

I have tweaked someone else's Processing sketch that used an extra size-2 dimension on arrays for storing x and y values to instead use a separate x-values array and y-values array and noted a significant speed increase, so am fairly confident in saying that an unnecessary array indexing is not something you want to have when aiming for performance.

In C, structs inside structs aren't a problem at all. A sub-struct is as easy to access and use as a "top level" struct. I don't know if it can be done in Java (a quick look just now for "Java structs" yields the impression of some heated debate about allowing struct-like behaviour in Java), but I have a feeling that people using (array[0],array[1]) instead of (field.x, field.y) because they saw someone else do it, without understanding why and perhaps believing something that is the opposite of the intention.

-spxl

We have PVector to hold a pair of coordinates...
I agree with Quark, using a structure (array or class) is better than using two variables. A big advantage is that you can return such structure, while you can return only one primitive value!

I think the "optimizations" discussed above are totally pointless!
Some concepts are indeed drawn from other languages, be them PHP, JavaScript, C or something else...
Frankly, unless you know how the Java bytecode is generated and interpreted, don't bother for such optimizations based on suppositions on how the JVM works...
Even more, the JIT (just in time compiler) does further optimizations, depending on vendor of the JVM, version of the latter, etc.
Note that the line defining final x and y is an half backed optimization: making them static would save memory (shared by all instances) in addition of the speed up (the compiler knows it can treat them as constants).

So, unless you can prove (by appropriate benchmark) that a version is faster (or uses less memory), just stick to the most readable, easiest to understand, thus to maintain, version.

Note: in current version of Java, creating too much objects can slow down a bit an application.
I have seen in the JBox2D forum that programmers gained much performance by filling fields of pre-allocated objects (mostly coordinates!) instead of creating an object on the fly and returning it.
That's because the library generates lot of such short lived objects. So it cumulated piles of garbage objects, making lot of work for the garbage collector. The reasoning might not be usable in your sketch...

Note you will find articles (like Java theory and practice: Urban performance legends, revisited) stating you should not make such optimization because (no more so) recent Java versions have escape analysis, which destroys the short lived objects on the spot (IIRC).
Except that you have to activate this optimization yourself!
I have seen that Java 7 should enable it by default...

Quark wrote on Oct 30^th, 2009, 7:15am:

I meant: has the Java community at large decided that objects suck and devolving to the use of (simple) arrays (when there are other options available) is just a better way to do things

I take it that the answer (in general, non hardcore otimisation cases) is 'no'.

On that basis, I suggest a bit of an education campaign, advocating the use of objects (such as PVector, Coord2D or whatever). As I mentioned, I have seen this use of 2-element arrays (or adding an extra dimension to some other array structure) a number of times, and if people (especially people new to programming and/or OO programming) keep seeing it they will keep using it.

Warning about use of Coord2D (as suggested by Quark)
Code:

Coord2D c = new Coord2D();
c.x = 23.5803;
c.y  = -1.296;

Coord2D c2 = c;

// c2 is _not_ a copy

c2.x = 99;

// c.x has apparently also changed to 99, as there is only one object 

-spxl

Quote:

Exactly! As you point out, procedural coding is simpler and less intimidating.
Using arrays is simpler than using ArrayLists, hence the tricks mentioned above which are quite common (not in the Java world! but in the Processing world, in the newbies category...).
Somehow, Processing even facilitates the usage of simple arrays with its functions for manipulating them (extending, truncating, etc.), slow but convenient for beginners.

The "assignment isn't a copy" is a good example of why OO can be perceived as difficult. Also the "I declared an array but it doesn't take my values" (no new), or "I made new Stuff[N] but I can't assign values to my objects" (no new Stuff() N times), etc. When users have a little background in other programming languages, it can be even more confusing!
But fortunately, motivated people learn quite quickly...

Note: I started to program, in Basic, on computers with 1MHz CPUs (yes, MHz, not GHz!). I coded a lot in C, quite a bit in assembly language, etc.
So my mind is used to micro-optimizations, which are quite important at such "speeds" and in these languages, interpreted or poorly optimized.
Today we have complex languages with optimizing compilers and VMs, etc., so we have to forget most of our prejudices on languages.
In C, it was stupid to write:
for (i = 0; i < strlen(str); i++)
because strlen computed the length of the string by iterating on it!
So it was better to pre-compute this value.
In JavaScript, you still had a gain by writing:
for (i = 0, l = str.length; i < l; i++)
for slightly different reasons. Even that might depend on the JS engine (different in Chrome, Firefox, IE...).
In Java, it is OK to put str.length() in the test part. The apparent call is probably optimized by the JIT compiler.

If you want to improve the performances of your sketch, first look at the tight loops, doing millions of iterations on each frame.
I often recommend to put stuff like smooth() from draw() to setup() if invariant, but it is not for speed, more for readability/logic.
And to optimize, measure times! Several times, since computers are multitask today. Find if an optimization really gain speed. Don't assume things.

Aside: see spxlOrigamiButterfly for example of replacing three-dimensional arrays with simple arrays and associated performance improvements (timed), listed in the program comments. Note that the optimisations (and timings) were performed in that order, so it is not clear what the last array manipulation may have had if it were done first.

-spxl

With regard to comparing arrays with objects consider this sketch
Code:

void setup(){
  float[] p = {2.878, 3.142};
  
  println(p[0] + "\t" + p[1]);
  
  float[] p2 = p;
  p2[1] = 9.999;
  
  println(p[0] + "\t" + p[1]);
} 

The output is
2.878      3.142
2.878      9.999
in other words p and p2 refer to the same array!

In fact Java treats arrays as objects so
Code:

  float[] p = {2.878, 3.142};

// is same as

  float[] p = new float[2];
  p[0] = 2.878;
  p[1] = 3.142;
 

In Java the new command instantiates/creates an object

In your butterfly program you were using multidimensional arrays, in Java a 2D array is a 1D array of arrays. A 3D array is a 1D array of 1D arrays of arrays. Might seem confusing but effectively we have a lot of arrays each one being treated as an object and is subject to same garbage collection rules as any other object.

In your program you started with 3D arrays e.g. folds[][][] when you need to access a particular element e.g. folds[5][0][1] Java has to do a lot of work first to find the location of array folds[5][][] then using the array at this location to find the array folds[5][0][] and finally find the element at folds[5][0][1] this is why you got improved performance when you used smaller dimension arrays you are reducing the number of calculations.

subpixel I love the origami butterfly it looks great.