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 | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode