Why don't you try out yourself and measure?

" the second one doesn't have to allocate(?) the space for "Entity e" each time?"
No. There is no allocation, e just gets the reference to the object from the collection, and it probably lives in the stack. Beside, the compiler takes care of such issues, ie. it optimizes the loop anyway. I bet the bytecode for both is identical.
And the first form is better, as e doesn't need to live beyond the loop: the smaller scope you give to variable, the better.

@mbraendle Yeah, I would, except I assumed the result would be too trivial to measure. :P

@phi.lho
     
Thanks, that makes sense, and good point about scope.
So I know that all that 'e' really holds in this case is the memory location of the particular Entity object. What then does the action of "Entity e;" actually do? Create a new pointer? See, that's where I thought it might take a little extra time...

There are no pointers in Java, only references. This kind of thoughts is familiar to me as I come from the C world, and I tend to think in micro-optimizations. And that's precisely the kind of question lot of people ask, including me at the start. I gave you the answer I saw frequently: don't think about such optimizations, trust the compiler to do the right thing, and think more in terms of readability, side effects (limit scope), and so on.

With modern compilers, reality is more complex that what you see, what intuition tells. Code is optimized by the compiler, and further changed by the JIT compiler (HotSpot for Oracle JVM) which observe dynamically the running code and translate to assembly code the parts that are frequently run.
If you really want to see what the javac compiler does (first compiler phase, generating .class files), take a bytecode inspector.

Some people will tell you that premature optimization is the root of all evil (a quote you can see quite frequently...) and while I agree now with this, I find this kind of question still relevant. Because there are still some idioms that are just totally inefficient, so learning to avoid them is better. For example, in C, don't for for (i = 0; i < strlen(someString, i++) because strlen will walk the whole string on each loop! (in Java, length is stored, so it is more efficient). In Java, don't use Boolean instead of boolean for the type of a simple variable (not going in a collection), as it takes more memory and it is slower (wrapped in an object). And don't concatenate strings in a loop with a simple + (use a StringBuilder instead). And so on.

In the https://forum.processing.org/topic/array-with-a-class-overwrites-old-one thread, I have meet one case where having the variables at the outer scope is actually a bug! Moving them to the most inner block solves the issue.

Very informative answer, thanks!
That's interesting about the code being dynamically observed.

And yeah, I'd heard that quote about optimization before. :) I just figured if there was a faster practice I could adopt from the start, I might as well.