@Dave1707 Once again, I don’t believe you are wrong, but I switched to your method of framerate averaging (ps. Instead of total could you use ElapsedTime?) and moved my loop up to 1000 and it’s still claiming 22fps for my rect and 6 for the other. Could it perhaps be a difference in iPad versions?
@LoopSpace Sometimes you’ll want a faster way of measuring FPS, rather than spending a ton of time and making an accurate one. If the faster way works good enough, go with it. Besides, you’re not even talking about FPS, you’re talking about framerate.
@monkeyman32123 When you run the test for your “rect” and get 22, then you run “rectangles.origrect” and get 6, are you commenting out your “rect” so you’re just running “rectangles.origrect” and not both of them. That’s a very large drop for the original rect function. Run my setup() and draw() functions below without including your rectangles code so it runs Codea’s rect function and see what value you get. If you want to use ElapsedTime, then you could use the code like what’s changed below. You’ll see the values are the same.
function setup()
rectMode(RADIUS)
total=0
count=0
t=ElapsedTime -- starting time
end
function draw()
background(40, 40, 50)
strokeWidth(5)
stroke(255, 0, 0, 255)
fill(0, 0, 255, 255)
for i=0,1000 do
rect(WIDTH/2,HEIGHT/2,50,50) --RADIUS
end
fill(255)
count=count+1
total=total+DeltaTime
text(math.floor(count/total),WIDTH/2,HEIGHT-100)
text(math.floor(count/(ElapsedTime-t)),WIDTH/2,HEIGHT-200)
end
I am commenting out my rect when I run the test, yes. Also, the test you just posted that doesn’t at all have my rect code is still getting only 6 fps. It seems that the codea built-in is faster on yours, but on mine, my code is far, far faster (even when calling noSmooth, thinking that might be the error in number, the codea built-in still only registered 13fps, which is still lower than 22)
@Monkeyman32123 That seems really strange. What device are you running the code on. I’m just wondering if other users with that device will get the same type of result if they try the code.
iPad 4th gen 16GB with retina display. Let’s try to get some other users in on these tests, if mine runs faster for some people then at least it can be helpful to some 
@SkyTheCoder In this situation, precision is uttermost as the question is about speed of particular types of code. So a “rough and ready” measure of framerate (I agree, but fps is what the variable was named) is not acceptable as a measurement. If the claim is that one type of code is faster, that claim had better be backed up by an accurate measure of the time taken.
@Monkeyman32123 I don’t get your question about keys. ipairs works by iterating through numerical keys until it hits a nil so the keys had better be consecutive otherwise the two types of code are not comparable.
I’ve been running some more tests and managed to get for to beat ipairs with enough iterations (in the 100,000 mark). The difference is swamped by the difference made when converting variables from global to local scope so that’s the better optimisation.
In addition, a while loop beats them both. Interestingly, the while loop that mimics ipairs (testing for a nil value) is faster than a while loop that mimics for (testing that the index is less than a limit).
So if you’re interested in squeezing out the very last drop of speed, go for while. However, the differences are so small that it is highly likely that there are better optimisations to be made in your code elsewhere.
Doing a Google search for Lua optimazation turns up several interesting links. But one thing that would be nice is to be able to see what the Lua code actually turns into when it’s run on an iPad. If you can see the low level instructions, then you could get a better idea of the number of instructions that have to be run for each Lua instruction. Different low level instructions take a different number of cycles to complete.
Doing a Google search for Lua instruction set or Lua bytecode also turns up some interesting links.
@Monkeyman32123, your rect function gives me an fps of 8/9, origrect gives me 6/7. Not a huge difference, but worth noting
(My poor iPad Mini can’t compare to yours or Dave’s 
)
Strange, different iPad versions seem to get vastly different results. Mine is faster in some cases, which is good for some people, but it makes me wonder why
I suspect it will depend on what spec machine you have, what version of iOS your running and what other apps you have running in the background (or background settings).
Don’t worry too much about “premature optimisation” - just follow good basic lua practices (caching of local functions, don’t allocate locals inside loops, be aware of dynamic memory allocation etc) and good Codea practice (only using smooth() when needed - using meshes instead of sprites etc).
Then when your app is actually up and running then look to see if the implementation can be improved. Often times it’s the actual logic that’s inefficient and massive gains can be got by improving your algorithm.
Just my $0.02