Codea 2.1 running code very slowly

Been running into a similar problem. Have noticed that since 2.1.1 things are about 30 percent slower than version 2.0

So in order to test this hypothesis I used some benchmarking software someone else had written. I’ve tried to locate it on the board, but nothing showed up. The app was designed to test Codea under pressure, by displaying a frame rate that decreases as the ball count on screen increases. Normally it starts at 60fps, and slowly drops as more and more balls come on the screen.

Under version 2.0 of Codea, on an iPad 4, the app could handle a maximum of 900 balls before it choked. This would require a forced shutdown of Codea, before restarting as it had locked me out, due in part to the single threading.

Under 2.1, the frame rate dropped and would stall at about 450 balls, before choking, but eventually I was allowed to exit the session and restart again. Upon restarting the session, it would invariably have a frame rate of 29 to 30 fps. I put this down to the problems of optimising that were to be fixed in 2.1.1.

However this does not seem to be the case. When running the app, this time using 2.1.1, it does achieve a better score, but only by a margin of 50 percent. Now the session will choke at about 600 balls, whilst allowing me to eventually exit. There is still the problem, that any new session, or a restart of the old benchmarking session, starts with a frame rate of 29 to 30 fps. The only solution to the problem is to force quit Codea. I have included a copy of the benchmark listing below.

Has anyone else seen this problem?

Codea 2.1.1
iPad 4
iOS 8.1.3

------List starts-------


displayMode(FULLSCREEN)    

function setup()
    physics.continuous=true
    tab={}                    -- table for balls    
    for x=1,25 do             -- start with 5 balls     
        create()
    end    
    line1 = physics.body(EDGE,vec2(5,5),vec2(5,HEIGHT-5))
    line2 = physics.body(EDGE,vec2(WIDTH-5,5),vec2(WIDTH-5,HEIGHT-5))
    line3 = physics.body(EDGE,vec2(5,5),vec2(WIDTH-5,5))
    line4 = physics.body(EDGE,vec2(5,HEIGHT-5),vec2(WIDTH-5,HEIGHT-5))  
end

function create()    -- create a new ball in the table
    local a=#tab+1
    tab[a] = physics.body(CIRCLE,10)
    tab[a].x=math.random(30,WIDTH-30)
    tab[a].y=math.random(30,HEIGHT-30)
    tab[a].friction=0
    tab[a].gravityScale=0
    tab[a].restitution=1
    tab[a].linearVelocity=vec2(math.random(-400,400),math.random(-400,400))
end

function collide(contact)
    if contact.state == BEGAN then
        -- if the red ball is hit, create another ball and sound
        if contact.bodyA.x == tab[1].x and 
            contact.bodyA.y == tab[1].y then
                create()
        end
    end
end

function draw()
    background(50, 50, 50) 
    fill(255)
    text(#tab,WIDTH/2,HEIGHT/2+20)
    strokeWidth(0)
    for z=1,#tab do
        fill(0, 47, 200, 255)    -- color of the blue balls  
        if z == 1 then           -- color of the red ball
            fill(255,0,0)
        end
        ellipse(tab[z].x,tab[z].y,20,20)
    end    
    stroke(255) 
    strokeWidth(5)
    line(5,5,5,HEIGHT-5)  
    line(WIDTH-5,5,WIDTH-5,HEIGHT-5) 
    line(5,5,WIDTH-5,5)
    line(5,HEIGHT-5,WIDTH-5,HEIGHT-5)
    fill(255)
    text(string.format("%d",1/DeltaTime),50,(1/DeltaTime)*15)
end

@Snowybear That code looks like something I wrote. When I run this and exit the code when the frame rate gets to about 4, I notice that the editor seems slow. I have to exit Codea and come back in for the editor to run normally. As I said in posts above, it’s hard to say what’s really happening without having the results of different programs that were run on the different Codea versions.

@Snowybear I ran the code again and exited the code when the frame rate got to about 4. When I restarted the code, I noticed that the frame rate showed 29 or 30 and also 58 or 59. I let it run and eventually the frame rate jumped to just 58 or 59. I let it run again until it reached 4 and exited the code. Running the code again showed the 29 or 30 and 58 or 59. After awhile it just showed 58 or 59.

Hi @dave1707, on my ipad 3, codea 2.1, fps starts dropping with only 90 objects moving. I remember i ran this very same sample one year ago or so and i was impressed by the amount of balls i could see moving at that time. Even if latest update made things much better i feel like codea doesn’t run smoothly as it used before 2.0.
Just my impression, i might be wrong

If I run this on my iPad 1 with Codea 1.5.5 , the frame rate is about 4 when I have 380 objects on the screen.

As said before, i’ve no chance to revert to codea versions earlier than current. I’d really do it if i could.
How many objects do you display smoothly, before fps drops down on your ipad 1?

@deactive On my iPad 1, the frame rate slowly drops as the number of objects increase. Once it gets over about 80, it stutters every now for an instant and then runs OK. The last time I ran it, I had a reading of 853 objects with 0 frames. It didn’t crash, it just didn’t update anymore. I closed Codea after about 5 minutes.

Thanks for that @dave1707. Dont you agree it’s weird we nearly meet the same performance with different versions of codea and hardwares?

Just to chip in my 10 cents (and coming a bit late to the party as I’ve been away) - im still experiencing about 50% slow down since the latest update.

This appears (like others are reporting) exclusively on mesh draws, everything else seems fine.

Bummer, I was hoping to get my game finished by Easter, I guess I’ll have to wait for another update to fix this :frowning:

Anyone else got any other observations?

@andymac3d if I can fix it soon you should just be able to download the new runtime libs rather than wait for Apple to approve the update.

Thanks @Simeon - that’s fantastic. :-D.

Ps. Out of curiosity, do you have a rough idea when the next update might be available?

@Simeon just to backup what andymac3d says, I’ve noticed making one mesh and adding plenty of rectangles works fine with normal speed afaik. However making individual meshes slows it down rather quickly which it should, but a lot more so than the previous version making me have to revert to using line().

@andymac3d @Luatee we’ve figured out the problem and it should be fixed. Thanks to everyone for providing benchmarks and example code.

I’ll post beta runtime libraries so you can export your projects and swap out the libraries to double-check the performance.

Thanks a lot, @Simeon

Ps. How to join the beta tester program? I think i’m good at spotting issues lately :slight_smile:

Great news, thanks for all your hard work @Simeon

Wow ! that was quick ! :slight_smile:
Thanks @Simeon !

Sorry if I missed something, but where can we get the runtime libraries ?

Hey @xdamon, those will be automatically downloaded along with your exported xcode project. If you run your exported code on a real device you’ll see the speed fix.