tuning for speed

[witeowl]

OK, I've finally finished(?) my rather monster project (for a beginner) and it's been quite some time since I tested it on my iPhone. Sure enough, it's sluggish on the actual device. Before I start trying to optimize my app by trial and error, can someone point me to some common causes of sluggishness and what tweaks might actually make a difference? Here are some of my thoughts:

1) Frequently, I call a quick handler to save my data array as a file. This handler resides in the main stack. Should I include this, instead, on each card? (Alternately, I have preOpenCard handlers for many cards, which ofter call similar handlers (setting up a scroller, etc.) - should I move these to shared handlers in the stack instead?)

2) This one might be confusing: I have a group of buttons with the same basic function, but different values and some slightly different behavior. I have the handler in the group and control it with switch statements by target. I can separate the group and give each button its own code, but then should I put the entire function put into each button's handler, or just put the values in the button and have each button call a handler on the card?

3) Is there any benefit to storing some data as custom properties of the stack or of buttons rather than global variables/arrays? This would have to be set up upon loading, as users can edit this data, but it's doable.

4) I have a nasty undo button that determines its behavior by looking at the contents of a field for key words or phrases. This means I'm using a series of if/then/else if statements. How likely is it that switch statements would be better? (They don't seem to be, based on #2, but maybe I'm wrong.)

Anything else I should look at? I'm not using animation except for push transitions between cards and changing the colors of some buttons. I've also eliminated the size of the data array as a possible culprit, as its speed appears nearly identical when it's a virtually empty array or full array.

Whew! That's a lot. Thanks for any input, unless it's just, "Woah, you're screwed, dude."

[bn]

Hi witeowl,

exactly what is sluggish? everything?

From what you describe I dont see anything in particular. All the rules for code optimization apply to the iOS and then some.

@ 1 saving to a file and reading from a file is more time consuming than setting a global or a custom property, you could save whenever appropriate.

@ 2 I would not worry about that.

@ 3 I dont think it is a matter of speed, it is more of programming style. Globals and arrays are fine, setting a custom property in my experience has a little overhead, but only noticeable if you do it thousands of times. Also queriing a property in a repeat loop is not a good idea. E.g. in a repeat loop the width of fieldx, the height of field x etc. Ask for it before the repeat loop and put it in a variable, saves some time.

In my experience what does slow down Livecode on the iOS is graphic effects and all sorts of screen updates. For fields it is quite fast as long as the field does not have shadows etc. If you want to go for shadows use an image instead of graphic effects.
If for example you put in the same script something into field 1 and field 2 you should lock the screen before you do that and unlock it afterwards. This saves you one screen update.
I would not worry about the preopencard handler for setting up a scroller, it works relatively fast in my experience.

4) I have a nasty undo button that determines its behavior by looking at the contents of a field for key words or phrases. This means I'm using a series of if/then/else if statements. How likely is it that switch statements would be better? (They don't seem to be, based on #2, but maybe I'm wrong.)

if/then/else is just as fast as a switch statement, again style and preference is at work here. What is important in working with field data is to take it out of a field and put it into a variable, then do your conditionals. Also, a

Code: Select all

repeat for each line aLine in tData

is considerably faster than

Code: Select all

repeat with i = 1 to the number of lines of tData

I don't know if your code uses a repeat loop. But this point is a big one if you do it often or the data in the field is large.

Nothing beats benchmarking: I try to isolate the things that are slow and make a field, put the milliseconds into a varible before the code and then after the code and display the difference in the field. This gives you a feeling where the slugginess is coming from. If you can narrow the slow parts of your code down to a certain handler then you could try to find ways around the slow parts.

These are just some of my thoughts other may have more to add.

Kind regards

Bernd

[witeowl]

Hi witeowl,

exactly what is sluggish? everything?

Actually, yes, it does feel like everything is sluggish, but there are a few places where it feels like it has to "think" after I push a button. Maybe it wouldn't seem that way to someone who never used the app within livecode or within the simulator, but it is/was quite a significant difference to me. And if I go to other apps, they seem to have a more zippy feel.

@ 1 saving to a file and reading from a file is more time consuming than setting a global or a custom property, you could save whenever appropriate.

I can take a look and make sure I'm only saving when something significant has occurred, but that is fairly often, as I don't want to risk losing a grade given to a student. I'm working on the assumption that the only way to ensure that data is safe in iOS, should the user hit the menu button, is safely saving it in its file - corrections to that assumption are welcomed. Otherwise, I think I'm just stuck with saving to a file.

If for example you put in the same script something into field 1 and field 2 you should lock the screen before you do that and unlock it afterwards. This saves you one screen update.

I'll double-check that. Thanks. This doesn't apply to visuals set in a preopencard, of course... (?)

I would not worry about the preopencard handler for setting up a scroller, it works relatively fast in my experience.

OK, that appears to be correct. The delay in switching to a card with a scroller does seem to be no worse than the delay in switching to a card without a scroller.

if/then/else is just as fast as a switch statement, again style and preference is at work here. What is important in working with field data is to take it out of a field and put it into a variable, then do your conditionals. Also, a

Code: Select all

repeat for each line aLine in tData

is considerably faster than

Code: Select all

repeat with i = 1 to the number of lines of tData

I don't know if your code uses a repeat loop. But this point is a big one if you do it often or the data in the field is large.

Oh, really? Interesting. I use quite a few repeat loops. That's definitely something to look at.

Nothing beats benchmarking: I try to isolate the things that are slow and make a field, put the milliseconds into a varible before the code and then after the code and display the difference in the field. This gives you a feeling where the slugginess is coming from. If you can narrow the slow parts of your code down to a certain handler then you could try to find ways around the slow parts.

Yes, I'll undoubtedly need to do that, but your response has helped with things to focus on (and what to not focus on). Is benchmarking within livecode equivalent to benchmarking on the device?

Thanks a ton for your thorough response!

[bn]

Hi witeowl,

as I don't want to risk losing a grade given to a student

I would say that depends on the grade but seriously of course data integrity is more important than zippyness, I agree.

This doesn't apply to visuals set in a preopencard, of course... (?)

preopencard is before screen drawing.

Is benchmarking within livecode equivalent to benchmarking on the device?

Benchmarking in the IDE scales for code but you still have to benchmark on the device, sometimes you find surprises there. And the visuals are the ones that take time. If you use go to next card with visual effect then set it to very fast.
Don't trust the Simulator, it fools you as far as speed is concerned.

Also, if you use functions/commands from inside a long repeat loop you might consider to put the code inline into the repeat loop. It again saves a little but depending on your repeat loop it might add up. The code is not as clean to read but execution speed might go up.

If you feel like it you might want to post the script of the button that you feel has the biggest lag. Then it is easier to see what is going on.

Kind regards

Bernd

[witeowl]

I would say that depends on the grade but seriously of course data integrity is more important than zippyness, I agree.

Haha, I can imagine it: "if tGrade >= 70 then saveMaster..."

If you feel like it you might want to post the script of the button that you feel has the biggest lag.

Thanks, again for all the help. I might come back and do that after I finish tweaking and benchmarking... if I still feel the need, of course.