That is running 255 * 255 * 255 = 16,581,375 times. That is going to take a long time, what are you trying to do?

you let the poor thing do 16,777,216 loops. so this are 3,355,443 loop per minute, 55,924 loops per second.
What do you expect?
Since this is no random-drawing and you always use the same values you might save the picture when finished.
So the next time it'll go faster.

It's not in a draw loop. It's just a static program so 16 million loops is nothing.

Can't processing handle something so simple?

point() tends to be extremely slow, it is best to use pixels[] with P2D

Here's your code using draw() as a type of outer loop iterator i.

As you'll notice, the 1st half of screen is drawn instantly.
You can see it clearly if you uncomment the noLoop() @ end of setup().

Problem is, the drawing keeps starting over from left after i>0.
It's a logical incompatibility between 3 parameters for stroke() and 2 parameters for point()!

P.S.: It doesn't take 5 minutes to complete here. It's about half minute!  

int i;

void setup() {
  size (01000, 0400);
  frameRate(100);
  noStroke();

  //noLoop();
}

void draw() {
  for (int j=0; j!=0400; j++)
    for (int k=0; k!=0400; k++) {
      stroke(i, j, k);
      point(i+j, k);
    }

  print(i + "\t");
  if (i++ == 0400)    noLoop();
}

You're absolutely right. Point is the culprit here. I had no idea it was this bad.

Without it the program runs in 1 second.

Thanks asimes!

About the not-in- draw() controversy:

Processing always draws, even inside setup().
The catch is that it only displays the result at the end of draw()!
B/c everything is "drawn" in a buffer.
And that buffer is finally transferred into canvas once each end-of- draw().

point() has to do lot of things, that's why it is slower than direct writing of color in an array.
Note also that you do 16 M iterations to draw 65,6535 (more or less) pixels, not very efficient either.