Tips for speed

[sritcp]

I was reading a recent post, when I noticed Klaus' admonition:

1. Avoid accessing FIELDS in repeat loops, that's a big slowdown!

I realized that such pearls of wisdom are strewn all over this forum and I remember reading many of them, but can't recall a single one !!!
Did someone say "repeat for each item ...." is faster than "repeat for each word ...." or "repeat for each line" ?
Or, when would the use of an array be slower than a list? Etc.

I am starting this topic for you veterans to post your LiveCode aphorisms for speed (in a sentence or two).
Please number and bold them (as I have done Klaus' tip above).

There are a lot of people like me who'd be grateful to have this collection in one place.

Thanks,
Sri.

[FourthWorld]

Most of the speed improvements you'll discover with LiveCode can be intuited if you think about how a computer has to perform what we're asking it to do.

Fields are complex structures, while custom properties less so, and variables even less. I wrote this metaphor some time ago to illustrate what the engine has to do to extract data from a field:
http://lists.runrev.com/pipermail/use-l ... 11478.html

As for "repeat for each line..." vs "repeat with i = 1 to the number of lines...", keep in mind that the engine needs to know what a line is, meaning it needs to examine every character in a chunk and count the CRs it encounters along the way.

With this:

Code: Select all

repeat for each line tLine in tData
   DoSomethingWith tLine
end repeat

...the engine will not allow the data being traversed to be altered during the traversal, so each time through the loop it only examines the characters until it comes to the first CR, then puts that in into tLine for your code to work on.

But with this:

Code: Select all

repeat with i = 1 to the number of lines of tData
    put line i of tData into tLine
    DoSomethingWith tLine
end repeat

...the engine first has to count the number of lines in tData every time through the loop, since there's no way for it to know that something called within the loop won't be modifying that data. On top of that, "put line i of tData into tLine" requires that the engine traverse all characters in tData from the beginning until it counts up the number of CRs matching i - every time through the loop.

While general rules like this can be useful, there are also times when optimal performance may be found through less intuitive means. For example, as fast as arrays are to access elements, in some cases traversing a delimited list with "repeat for each line" can be faster - but even there we have no strict rule, because the depth of the array will matter (each level of an array requires a hash to access), and the number of items and the total line length can also affect which solution may be optimal.

Most things in LiveCode are fast enough that you don't need to worry about "best", and like as said, "best" often depends on the particulars of the data and what you want to do with it.

To get going just write your code so that it works, and if it seems slow post it here and we'll see if we can optimize it.

Like Donald Knuth said, "Premature optimization is the root of all evil."

If you take an interest in exploring options for optimization, I've outlined some benchmarking tips here:
http://livecodejournal.com/tutorials/be ... vtalk.html

[sritcp]

If you take an interest in exploring options for optimization, I've outlined some benchmarking tips here:
http://livecodejournal.com/tutorials/be ... vtalk.html

Richard,
Yes, I have gone through that article (and others on your website) and found it very useful.

I have, however, found thumb rules to be very useful, as something to start with.

Regards,
Sri

[FourthWorld]

I have, however, found thumb rules to be very useful, as something to start with.

As an optimization fan myself I can certainly appreciate that, but with a high-level flexible tool like LiveCode what I've found over the years is that such rules are better represented in a decision tree than a list.

Think like a computer and you'll be able to account for most of them on your own as you go.

For more nuanced optimization opportunities, we'll have to look at the specifics at play....

[FourthWorld]

Extra credit:
http://lists.runrev.com/pipermail/metac ... 04415.html
http://lists.runrev.com/pipermail/metac ... 04469.html
http://lists.runrev.com/pipermail/metac ... 04539.html

Worth reading, but don't forget Knuth.

[sritcp]

Extra credit:
..................
Worth reading, but don't forget Knuth.

Thanks for the links.
Notwithstanding your reservations, I couldn't help adding another. I hope you don't mind!

2. Don't use a repeat loop to determine the state of the mouse; use, instead, handlers (of messages) such as mouseMove, mouseDown, mouseRelease, etc.

I got this from an article by Jacque on her website, and the underlying principles have been useful to me in quite different contexts.

Regards,
Sri

[FourthWorld]

That's a very good example of "Think like a computer" you can extrapolate from: just as there are various ways to hone performance of what happens inside of a loop, we can also ask whether we need a loop at all.

In the case of mouse and keyboard message, the OS already maintains its own loop, polling the hardware for various states and actions, and then doling out messages based on those. So in most cases, if you find yourself tempted to poll for status of any system element, check the Messages list in the Dictionary to see if perhaps that's already being done for.