Improving performance in Codea

Usually, Codea is fast enough that you don’t need to worry about performance. But if do you need more speed, see this post

Wow, that is cool and most helpful @Ignatz

Do you think there’s a performance gain if I read all my images in the main setup instead of where they are used in separate classes?

As long as you don’t have too many, and you only read them once (into a variable) there should be no difference.

I usually have a function that reads in all the images, rather than reading them in one by one in different places in the code. But that’s a preference, not a performance thing.

Yup, I always have an Assets tab.

Another way to increase the speed of Codea is to buy a faster device. I think that would be Apples suggestion.

If you’re writing apps for the store, you have to cater for older devices, though

If you’re writing apps to make money, then yes, you have to cater to the older devices. But if you make money by selling new devices, then you add more code and use more memory to slow the older devices down to force the users to buy new devices.

I think we should leave that to Apple, our goal if we want to make money is to include as many users as possible!

Anyway, it’s always good to know what is fast and what is not. At least, I think so.

@Ignatz @Simeon I just wish that Codea had a better timer. Something that was external to Codea so if I wanted to time a math function in a loop, I could. If I did something like

function setup()

I would get different values from clockTicks.

If I do

function setup()

the values from ElapsedTime are both 0.

ElapsedTime/ DeltaTime just reflect the time at the beginning of each cycle. Do a test in the draw loop, and then the DeltaTime at the beginning of the next click shows you the speed. @Ignatz did you post your timer code that uses that method? I couldn’t see a link to it in the blog

@yojimbo2000 But you can’t time sometime in the same function. DeltaTime can’t be smaller than 1/60 of a second because draw take 1/60 of a second between draw calls.

@dave1707 - timing something that takes a tiny fraction of a second will be unreliable able because your device is multi tasking and may be busy with other things which distort such a tiny measurement. It’s better to do many tests and average them.

@yojimbo2000 - I didn’t post the code, I meant to but forgot. I’ll have a look at fixing that.