Speed up a slow loop

[J. Landman Gay]

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