There will be virtually no difference between the 2 versions of the code above. The 2ms difference you got was almost certainly caused by something else e.g. another background process since OS and Windows are multitasking.

As to being outsmarted, the Java has an incredibly powerful optimizing compiler which does its best even with badly designed

Declaration and use of primitive data types have virtually no effect on performance. It is the creation of objects (with the new command) and garbage collection than can eat into your performance and if possible you should avoid using new inside a loop.

Hi,

It's memory related. Also, it's bit for young players, because most people (including me) makes the mistake to declare variables inside a loop or function. That's why the brackets are so handy.

You can also declare variables outside a function. This runs on 2 ms. (?!?!?) :

1. int start;
2. void setup() {
3.   start = millis();
4.   float bezierLength = 6;
5.   float targetL = 7;
6.   float l = 0;
7.   float t1 = 2;
8.   float t2 = 3;
9.   float xPos1 = 4 ;
10.   float yPos1 = 5;
11.   float zPos1 = 6;
12.   float xPos2 = 7;
13.   float yPos2 = 8;
14.   float zPos2 = 9;
15.   int steps = 8;
16.   for (int i = 0; i < 185000000; i++) {
17.     bezierLength = 6;
18.     targetL = 7;
19.     l = 0;
20.     t1 = 2;
21.     t2 = 3;
22.     xPos1 = 4 ;
23.     yPos1 = 5;
24.     zPos1 = 6;
25.     xPos2 = 7;
26.     yPos2 = 8;
27.     zPos2 = 9;
28.     steps = 8;
29.   }
30.   println(millis()-start);
31. }

Ok then i have to do some more complex optimization to gain speed :)

As quarks said, beware of self-made micro-benchmarks!
The compiler probably makes the same bytecode out of your two loops (optimization).
And HotSpot, the Just-In-Time compiler can kick in and change dramatically the game...

A slightly better way of measuring performances is to use the Caliper library. At least, it can be used to avoid the most obvious pitfalls (like string concatenation with + in a loop instead of using StringBuilder, using loadXxx unconditionally in draw(), etc.).

To coin to old saying about optimization:
- Rule 1: Don't do it (ie. have faith in the quality of the compiler)
- Rule 2: Don't do it yet (ie. make your code to work before thinking about optimizing it)
- Rule 3: Do it only if necessary (ie. because the slowdown is really a problem)
And, of course, measure, with good tools...

my code above was just to isolate something.