Making Revolution faster using dimensioned arrays
Dennis Brown
see3d at writeme.com
Fri Jul 8 11:47:17 EDT 2005
On Jul 8, 2005, at 9:09 AM, Marielle Lange wrote:
> Dennis
>
> I would be interested to know if in you timing test, you also tried
> using a
> variable rather than an array.
>
> repeat for x in (trows)
> repeat for y in (tcolumns)
> do something on (variable & "_" & x & "_" & y).
> end repeat
> end repeat
Marielle,
The do operator would be very slow, as it has to compile the line,
then execute it.
+ what if you store all rows in one array rowdata[1] and all columns
in another
one columndata[1]. You then reduce the dimensionality and perhaps
access time.
Yes, I have organized data both ways at times to get the best access
method
I do try to limit the number of accesses as much as possible.
Whenever possible I use the form:
repeat for each line theLine in textArray
repeat for each item theItem in theLine
process theItem
end repeat
end repeat
which is about as fast as you can get, but many times I need to index
into the data so I might use:
split textArray by return
repeat with i-2 to 1000 step 5
put textArray[i] into itemArray
split itemArray by comma
repeat with j=2 to 1000 step 3
process itemArray[j]
end repeat
end repeat
I might also mix the two forms to get the most speed.
I try to make the most of what Rev has to offer today in how I
organize my data. However, that requires a lot more thought, and you
have to understand what is fast and what is slow in Rev. It is just
not the case that you can solve the problem in the most straight
forward way --if you care about how long it takes to get the answer.
For simple things, it usually does not matter, but for complex
applications, the speed is important. The crazy thing is that with
Rev, doing more complex applications is more practical for the
amateur programmer, but the results are unsatisfactory due to the
speed of execution. There is no reason in my mind that precludes
having both ease of use and reasonably fast speed for the speed
critical portions of an application.
Dennis
More information about the use-livecode
mailing list