Speed up a slow loop
J. Landman Gay
jacque at hyperactivesw.com
Thu Mar 3 15:28:10 EST 2022
On 3/3/22 12:53 AM, Mark Waddingham via use-livecode wrote:
>
> If the difference between `the milliseconds` before the loop, and then after is 0 or 1
> millisecond - then that is how long it is taking. This means the issue is somewhere else. Are
> you sure there isn't anything you are doing either before that loop or after that loop which
> doesn't wait for ages (due to the ANRs you mentioned).
Today I'm getting slightly faster results. Repeatedly creating new boards is not slowing down.
Maybe some background processes were stopped (there was a system update last night.)
The scoring handler does three things with the user word list, calling out to 3 different handlers:
1. Remove any duplicates
2. Check the dicionary for the remaining words
3. Walk the board for each word to ensure it's a legal path
I just ran tests with LC 9.6.6 on a Pixel 5 that timed each callout independently. Times are in
milliseconds. No words were longer than 4 letters.
Dupes Dictionary Boardwalk word counts
12 1954 1404 -- 5 wds + 2 dupes, 2 illegals (total 9)
1 1934 2542 -- 9 wds, all legal
0 1960 1966 -- 7 wds + 2 illegals (total 9)
0 1921 1142 -- 4 wds, all legal
17 2015 8321 -- 30 wds + 1 dupe, 1 illegal (total 32)
My recursive board walk could probably be optimized but for now I'm just focusing on the
dictionary lookup. For reference, here is the whole handler:
function checkDictionary pList -- plist is the user words
repeat for each line l in pList
if sDictFile[l] = true then put l & cr after tCheckedList
else put l & cr after tNonWords
wait 0 with messages -- prevent ANRs
end repeat
set wholematches to true
put fld "wordList" into tWList -- no longer the same as pList since removeDupes has already run
repeat for each line l in tNonWords -- mark non-words in list
set the textcolor of line lineoffset(l,tWList) of fld "wordList" to "red"
end repeat
if tNonWords <> "" then put tNonWords into sStats["unknowns"] -- for later display
return tCheckedList
end checkDictionary
I suppose the delay could be updating the field? But updating a field for 2 or 3 entries
shouldn't take too long, should it? Also note that in the 2 runs where there were no illegals,
the timings didn't vary much. The checkDupes handler also colorizes duplicate words, which is
why those 2 runs have longer times.
> If there are only 3 reasonable length words in pList (I.e. 3 lines) then there's no way that
> loop can take 4 seconds.
When testing I don't have patience to think, so all words are usually 3-4 letters each.
>> Even stranger: on my cheapo Android tablet with 4 megs of RAM running
>> Android 9 the response is nearly instantaneous, even if the user list
>> has 200+ words. On my Pixel phone with 8 megs of RAM and Android 12
>> the response is slow enough to trigger the ANR with only 3 words. I'm
>> building for ARM 64.
>
> This strongly suggests it is something else either on your phone, or in your code which your
> phone doesn't like I think.
I have two Pixels, a 5 and a 6, and they both behave the same (slow) way, though the 6 has the
new Tensor chip. Yesterday I was wondering if the delay isn't the calculations but rather the
screen redraws. I have a lot of controls stacked up on the card, though many are not visible.
However, I've run the handlers with the screen both locked and unlocked with no changes.
--
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
More information about the use-livecode
mailing list