Hi.
I’m reading through the core code to get a feel for how things are done and maybe learn a thing or three. So when I find something I don’t understand perhaps it’s a reason it’s done this way. So I ask 
In ParticleEmiter.updateParticle there seems to be two ways of doing vector math here:
[java]
p.velocity.x -= gravity.x * tpf;
p.velocity.y -= gravity.y * tpf;
p.velocity.z -= gravity.z * tpf;
temp.set(p.velocity).multLocal(tpf);
p.position.addLocal(temp);
[/java]
Why is that done instead of always using a temp vector like this:
[java]
temp.set(gravity).multLocal(tpf);
p.velocity.substractLocal(temp);
temp.set(p.velocity).multLocal(tpf);
p.position.addLocal(temp);
[/java]
or if doing math against the fields is faster why not this:
[java]
p.velocity.x -= gravity.x * tpf;
p.velocity.y -= gravity.y * tpf;
p.velocity.z -= gravity.z * tpf;
p.position.x += p.velocity.x * tpf;
p.position.y += p.velocity.y * tpf;
p.position.z += p.velocity.z * tpf;
[/java]
or I think it could even be done like this (4 method calls instead of 6):
[java]
p.velocity.subtractLocal(gravity.mult(tpf, temp));
p.position.addLocal(p.velocity.mult(tpf, temp));
[/java]
It can probably be argued that the JVM will detect that the vector methods can be inlined so I think the performance of these three methods are probably about the same. (I’m no JVM hotspot expert though)
On a related note:
Since gravity is a global thing couldn’t it be calculated once per frame instead of once per particle?
by just having this member variable:
[java]
private transient Vector3f gravityPerFrame = new Vector3f();
[/java]
doing this first in updateParticleState:
[java]
gravityPerFrame.set(gravity).multLocal(tpf);
[/java]
and each particle update only do this (or some other version, see above)
[java]
p.velocity.substractLocal(gravityPerFrame);
temp.set(p.velocity).multLocal(tpf);
p.position.addLocal(temp);
[/java]
And yes I’m aware this is like 5 lines in a big code base and in the grand scheme of this this is probably a minor detail.
Theres no big difference in these, stuff you can do at code level is mostly cosmetic/for your own sake, the compiler optimizes the code much more (through inlining and many more operations) than you could by “optimizing” your code manually.
That is certainly true for the first variations. But for for the one where “gravity will be the same for the whole loop” that’s not something the compiler can know (I don’t think).
But I can see that we’re talking about small amounts of cpu loss here.
Why is it so easy to fall into the premature optimization trap
My logic probably should have been “humm my particle emitter is slow. lets profile it and see why”.
My bets are on that vector math isn’t the bottleneck 
Thanks for your time.
Most overhead is in moving the mesh, pushing stuff to the GPU via the system bus.