Re: Comparative speed in switching among groups

[David Epstein via use-livecode]

Many thanks to Richard, for his interesting results and for the reminder that 
speed testing is pretty easy.  I ran a similar test on a slightly different 
task--flipping among 50 different groups, or 50 different cards--and got 
similar results.  Adding a “lock messages” sped up the card option by a factor 
of 4, but the group option was much, much faster even then.
I’m trying to make it possible to scan quickly through a long document.
The remarks of Richard and Alex raise these questions for me:
1.  Is LC recalculating the line wraps of all fields every time we go to a 
card?  Is it not doing that when a hidden field on a card is shown (or is the 
field somehow “ready to go” even when the field is hidden)?
2. On the question of resizing:  One possibility is to adjust groups when 
(i.e., just before) they are shown.  But would it be speedier to do this in 
advance, when nothing else is happening?  The User Guide says “timer based 
messaging [is] ideal where you want your user interface to remain responsive.”  
I’m not sure exactly how to do this, but it seems like on a resize event one 
could make a list of the hidden groups that need to be adjusted, and call them 
one at a time with something like 
send “upDateGroupLayout oneGroupID” to me in 10 milliseconds.  Is that right?

David Epstein

___
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

Re: Comparative speed in switching among groups

[ambassador--- via use-livecode]

Alex Tweedly wrote:

> On 27/11/2023 00:02, ambassador--- via use-livecode wrote:
>> I suspect most layouts won't encounter this much of a difference. After all,
>> I did choose the elements I could put together quickly with rendering 
>> impairment
>> in mind. 
> 
> But there is another consideration. When (if) you resize the stack, the 
> 'group' version will need to resize each of the groups (even when they 
> are hidden), and if the number of different groups is non-trivial, that 
> might make resizing slow.

True, there are many other cases where rendering speed will show itself, and 
resizing is one that will come up throughout a session.

My example only covered the transition speed as requested because I don't have 
the time I used to. LiveCode's decline in the market has me building a new 
business.  It's been a long time since I've built a business from scratch; 
turns out it's not much easier than I remember it. :)

The big performance difference here isn't so much the number of groups but 
what's in them.  I'd guess the fields alone are the biggest time sink, 
calculating line wraps for 20k text with no carriage returns.  With six of 
those fields it's almost silly to have that much text rendered below the fold 
at once; showing only the visible portion with a deferred loading of the rest 
would make things much snappier all around.

I've made many layouts with deeply-nested groups. But outside of artificial 
stress tests like this I generally don't see load and save times as long as I 
see with this test stack.


> >  And now I'm curious: what are you working on where layout transition speed 
> > is critical?
> 
> Hmmm. Doesn't your test case already take 2-1/2 seconds to change card ? 
> (13 seconds for 5 iterations).

Yes, hindsight is always illuminating. :) But the question would not have been 
posed if the answer was known in advance.

Given how often we use the card model provided, if the delay were this 
significant more often we all would have abandoned the practice long ago.  But 
for most things card-to-card speed is more than adequate, and sometimes useful 
for organzing things during the development workflow.

My own work has used both cards and groups, depending on particulars unique to 
the project. But now I'm also a little more aware of overall perfortmance 
degradation with line wrap calculations and images larger than their displayed 
size. 

Richard Gaskin
FourthWorld.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

Re: Comparative speed in switching among groups

[Alex Tweedly via use-livecode]

On 27/11/2023 00:02, ambassador--- via use-livecode wrote:

An excuse to benchmark?  Sure, I'll bite. :)


:=).  Beat me to it.

But boy oh boy was I surprised by the difference.
Bottom line, in millisecs for just 5 iterations on an M1 Mac:

Groups: 141
Cards: 13619


Wow!



I suspect most layouts won't encounter this much of a difference. After all, I 
did choose the elements I could put together quickly with rendering impairment 
in mind.


But there is another consideration. When (if) you resize the stack, the 
'group' version will need to resize each of the groups (even when they 
are hidden), and if the number of different groups is non-trivial, that 
might make resizing slow.


I took Richard's test stack and resized each of the the text fields  to 
approx 1/3 of the stack width - and that was already painfully slow with 
two groups. So if you aim to have a large number of groups, you may be 
forced to overcome this yourself.


You can do something like

on resizecontrol
   if the visible of me then
  .
   end if
end resizecontrol

and be sure to add a

   send "resizecontrol" grp tGroup

immediately after you make group 'tGroup' visible again.


But I suspect the difference would still show itself in lighter layouts.

And now I'm curious: what are you working on where layout transition speed is 
critical?

Hmmm. Doesn't your test case already take 2-1/2 seconds to change card ? 
(13 seconds for 5 iterations).


That's plenty long enough to annoy me. I get frustrated (for example) 
with the forums, because of the 1-3 seconds it takes to transition from 
one interesting topic to the next.


I have no idea what current UI thinking is - and I admit that the 
increasing use of the web and online access has probably increased 
people's acceptance of small delays - but back in the day I was used to 
aiming for sub-second response to complete *most* user actions.


Alex.
___
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

Re: Comparative speed in switching among groups

[ambassador--- via use-livecode]

An excuse to benchmark?  Sure, I'll bite. :)

I didn't test the third option because I feel confident we'd find it similar to 
the second but with the extra overhead of object/memory allocation.

My hunch was that groups would be faster than cards, because everthing needs to 
be unpacked and ready to go on a card but when going card-to-card there's 
presumably some setup and teardown.

But boy oh boy was I surprised by the difference. 

A bit about the test stack:

I wanted a worst-case scenario, looking for things we know take a lot of 
rendering time. So I made a group with a field containing > 20k chars so 
there's a lot of line wrap calcs, a fairly sizable image shrunk small with 
resizing set to "best", and two buttons so the engine needs to coordinate with 
the OS.

Then I replicated that group so there are three copies, grouped that and set a 
blue background, then made a copy of that bigger group and set it with a red 
background so we can tell them apart.

Then I copied the blue group to a second card, the red to a third, and wrote a 
script that does the timing of each.

The test stack I used is here (I added "SLIM" to the name because the first 
version I attempted had more than twice as many subgroups and took too long to 
work with, lots of beach balls on card-to-card and even saving):

https://fourthworld.net/lc/TransitionTimingTest%20SLIM.livecode


Bottom line, in millisecs for just 5 iterations on an M1 Mac:

Groups: 141
Cards: 13619

And even that was after adding a couple details to the group hide/show so I 
could tell they've changed, with a lock/unlock and a wait 0 you probably 
wouldn't need in production.

I suspect most layouts won't encounter this much of a difference. After all, I 
did choose the elements I could put together quickly with rendering impairment 
in mind.

But I suspect the difference would still show itself in lighter layouts.

And now I'm curious: what are you working on where layout transition speed is 
critical?

--
Richard Gaskin
FourthWorld.com



David Epstein wrote:

> Does anyone have practical experience or an understanding of the engine that 
> would
> cast light on the relative speed of some alternative ways of doing things?  I 
> want
> to switch among a number of different groups, each of which may contain its 
> own
> fields, graphics, buttons, and images.  Possible approaches:
>
> - Have many different cards, each with a group peculiar to it, and GO TO each 
> card
>   as desired, or
>
> - Have one card, with many different groups, and SHOW/HIDE the groups as 
> desired, or
>
> - Have many different cards, each with a group peculiar to it, and COPY a 
> group from
>   an unseen card to a single card that is always seen (and DELETE the 
> unwanted group
>   on that single card).
>
> There are other considerations that affect a choice among these methods, but 
> my concern
> here is the speed with which I can switch from displaying one group to 
> displaying
> another.   I am wondering whether at some level these methods all amount to 
> the same
> thing from the engine’s point of view (since everything is in RAM in any 
> case).

___
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

Re: Comparative speed in switching among groups

[Mark Talluto via use-livecode]

Hi David,

We made an app development environment that does this. It is very fast and 
comes with some benefits. One is you can do a good swipe between screens. 

Feel free to try it and see what the performance is like. The link is below.


Best regards,
Mark Talluto

appli.io 
livecloud.io 
nursenotes.net 
canelasoftware.com 



> On Nov 25, 2023, at 2:35 PM, David Epstein via use-livecode 
>  wrote:
> 
> - Have one card, with many different groups, and SHOW/HIDE the groups as 
> desired, or

___
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

Re: Comparative speed in switching among groups

[Bob Sneidar via use-livecode]

My understanding is that the second method of show/hide groups will be more 
efficient. 

Sent from my iPhone

> On Nov 25, 2023, at 14:36, David Epstein via use-livecode 
>  wrote:
> 
> Does anyone have practical experience or an understanding of the engine that 
> would cast light on the relative speed of some alternative ways of doing 
> things?  I want to switch among a number of different groups, each of which 
> may contain its own fields, graphics, buttons, and images.  Possible 
> approaches:
> 
> - Have many different cards, each with a group peculiar to it, and GO TO each 
> card as desired, or
> 
> - Have one card, with many different groups, and SHOW/HIDE the groups as 
> desired, or
> 
> - Have many different cards, each with a group peculiar to it, and COPY a 
> group from an unseen card to a single card that is always seen (and DELETE 
> the unwanted group on that single card).
> 
> There are other considerations that affect a choice among these methods, but 
> my concern here is the speed with which I can switch from displaying one 
> group to displaying another.   I am wondering whether at some level these 
> methods all amount to the same thing from the engine’s point of view (since 
> everything is in RAM in any case).
> 
> Many thanks.
> 
> David Epstein
> 
> ___
> 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
___
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

Comparative speed in switching among groups

[David Epstein via use-livecode]

Does anyone have practical experience or an understanding of the engine that 
would cast light on the relative speed of some alternative ways of doing 
things?  I want to switch among a number of different groups, each of which may 
contain its own fields, graphics, buttons, and images.  Possible approaches:

- Have many different cards, each with a group peculiar to it, and GO TO each 
card as desired, or

- Have one card, with many different groups, and SHOW/HIDE the groups as 
desired, or

- Have many different cards, each with a group peculiar to it, and COPY a group 
from an unseen card to a single card that is always seen (and DELETE the 
unwanted group on that single card).

There are other considerations that affect a choice among these methods, but my 
concern here is the speed with which I can switch from displaying one group to 
displaying another.   I am wondering whether at some level these methods all 
amount to the same thing from the engine’s point of view (since everything is 
in RAM in any case).

Many thanks.

David Epstein

___
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

Speed Improvements

[Bob Sneidar via use-livecode]

Hi all. 

I put a compiled version of Forms Generator 8 on a PC recently, and I would 
like to say that the speed improvements are very substantial from what I was 
experiencing in the past. SQL queries as well as file operation seem to be 
almost as fast as on my MacOS laptop. I would not hesitate to distribute a 
Windows app now, whereas before I would have been hard pressed. 

I will say that I streamlined my code to ensure I was not inadvertently 
re-querying for the same data, and the VM I am running it on has been migrated 
to another server, but even still I had tested on new PCs with SSD drives in 
the past and was getting disappointing results, whereas now I can hardly blink 
and a full query dataset is loaded and displayed. 

Kudos to the dev team! 

Bob S


___
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/14/22 2:09 PM, J. Landman Gay via use-livecode wrote:
I've updated the zip file download to include the resources needed; icons for all platforms 
(but the Windows one is very old) and a copy of the font. Update your standalone settings to 
accomodate the paths you need.


Sorry, wrong link originally, here's the correct one:



--
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

One last thing. Scott Morrow was good enough to build for iOS and send a screenshot. I was very 
pleased to see it went cross-platform without any significant problems (thank you LC!) but the 
custom font was missing, which makes sense since I didn't include any external resources. That 
reminded me that it probably didn't have an icon either.


I've updated the zip file download to include the resources needed; icons for all platforms 
(but the Windows one is very old) and a copy of the font. Update your standalone settings to 
accomodate the paths you need.




Thanks guys.

On 3/12/22 3:32 PM, J. Landman Gay via use-livecode wrote:
I have to thank everyone who helped me figure out my Boggle game. I've put the current file on 
Google Drive for anyone who wants to take a look. The scripts are open and I think I've removed 
all the testing cruft that accumulated over the last couple of weeks.


I'd be interested in any feedback or improvements. There's a Read Me in the zip file with more 
info.




Thanks so much to all! Contributors have been credited in the scripts.

Jacque




--
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

I have to thank everyone who helped me figure out my Boggle game. I've put the current file on 
Google Drive for anyone who wants to take a look. The scripts are open and I think I've removed 
all the testing cruft that accumulated over the last couple of weeks.


I'd be interested in any feedback or improvements. There's a Read Me in the zip file with more 
info.




Thanks so much to all! Contributors have been credited in the scripts.

Jacque

--
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/9/22 5:09 PM, Alex Tweedly via use-livecode wrote:


  - you can reuse the same tile later in a word (e.g.
Y  L  A
X  E  T

would allow "lately" as a word.

OR

- you can double-up on a tile (e.g. M I L would allow 'mill')
(more important if you're British than if you're American :-)


That's CHEATING! :) But while I've been testing I thought of a way I'd like to play. You can 
get credit for a made-up word if you can supply a clever enough definition for it that the 
other players agree is good enough.


Something like these neologisms (winners in the 2005 neologism contest,) only not real words 
like these are:


1. Coffee (n.), the person upon whom one coughs.
2. Flabbergasted (adj.), appalled over how much weight you have gained.
3. Abdicate (v.), to give up all hope of ever having a flat stomach.
4. Esplanade (v.), to attempt an explanation while drunk.
5. Willy-nilly (adj.), impotent.
6. Negligent (adj.), describes a condition in which you
absentmindedly answer the door in your nightgown.
7. Lymph (v.), to walk with a lisp.
8. Gargoyle (n.), olive-flavored mouthwash.
9. Flatulence (n.) emergency vehicle that picks you up after you are
run over by a steamroller.
10. Balderdash (n.), a rapidly receding hairline.
11. Testicle (n.), a humorous question on an exam.
12. Rectitude (n.), the formal, dignified bearing adopted by
proctologists.
13. Pokemon (n), a Rastafarian proctologist.
14. Oyster (n.), a person who sprinkles his conversation with Yiddishisms.
15. Frisbeetarianism (n.), the belief that, when you die, your Soul
flies up onto the roof and gets stuck there.
16. Circumvent (n.), an opening in the front of boxer shorts worn by
Jewish males


--
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

My memory checks on the Pixel 5 had a maximum app memory use of about 375 
MB of RAM. I think that was before I removed the duplicate copy of the 
dictionary data though, which if so would bring the total down.


That said, other apps had more. Chrome browser used over 300 MB, Play Store 
411 MB,  my mail client 211MB. Those do okay on the phone. And I still 
don't understand why my cheap tablet with half the RAM handled anything I 
threw at it, including SOWPODS, without blinking.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On March 9, 2022 6:53:46 PM Neville Smythe via use-livecode 
 wrote:



After button 2, the real memory used is 121 MB (second run 131 MB)
   So splitting a 2.5 MB file into an array with 275 K keys required 75 MB 
   (this figure was duplicated in the second run)




___
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

Re: Speed up a slow loop

[Neville Smythe via use-livecode]

I just ran a test to try to find out how much RAM is used when you create a 
large array; the result is rather surprising.

 BTW Bob: I did not imply that an array is implemented in LC as a database. 
Merely that to work its magic it must be indexing keys somehow. 

I had suggested a 2.5 MB list of 275K words might expand to no worse than 10MB 
when split into an array. Not quite, as it turns out.

I wrote a very simple stack which just has two buttons. 

The first reads SOWPODS.txt into a global variable gWordlist. Don’t try putting 
that variable into the msg box — LC becomes unusable with the Beachball of Hope 
spinning for a few seconds whenever you do anything. Aha, it is the LC engine 
that is having problems with large data (in this case displayed in a field of 
course, not in the variable itself)

The second button puts gWordlist into aa, and splits aa by CR  as a set.

I then turned the stack into a standalone and looked at the memory used in the 
Mac Console

. When the stack launches, real memory used is 29.8 MB (in a second run 45 MB)
That’s the basic LC engine + 18 MB of Mac OS stuff which is shared with 
all apps, the stack itself would be tiny

. after button 1, reading in the 2.5 MB file, the real memory used is 46 MB 
(second run 56 MB)
So 16 MB to store a 2.5 MB file in a variable (in the second run 11 MB, 
I guess 5 MB of engine code was garbage collected)

. After button 2, the real memory used is 121 MB (second run 131 MB)
So splitting a 2.5 MB file into an array with 275 K keys required 75 MB 
(this figure was duplicated in the second run)

We are now talking pretty large amounts of memory that the LC engine has to 
move around, for example probably making copies in its procedure stacks (that's 
stack in the coding sense).

I'm not surprised that LC might be getting indigestion with variables of this 
size on a small device. I seem to remember running into RAM allocations for an 
iOS app measured in the low hundreds of MB.

Neviille
___
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

Re: Speed up a slow loop

[Alex Tweedly via use-livecode]

Hmmm - I have to correct myself :-)

It's not 110; there are 144 digraphs on a 5x5 board

 - nine centre tiles each have 8 neighbours

 - four corner tiles each have 3 neighbours

 - twelve remaining edge tiles each have 5 neighbours

giving 72 + 12 + 60 - so 144 pairs (already including both directions 
for each adjacency).


Now if you allow edge-to-edge wrapping (i.e. from the top right tile you 
can move to the right - and find yourself back on the top left, etc.) 
then there are simply 25 * 8 pairs - but then you've moved a long way 
from genuine Boggle rules :-)


Alex.

On 09/03/2022 23:09, Alex Tweedly via use-livecode wrote:
Yes, Quentin's allowing for diagonals (that's how the number of 
digraphs on a 5x5 board gets up to 110).


And it's probably a good idea, allowing an even finer filter - if you 
aren't doing the boardwalk method..


If you do use the boardwalk to generate the exact list of words, you 
get no benefit from single-letter or digraph filtering, because the 
tree-walk is constrained to only those valid "next char"s, and so 
implicitly avoids using those non-present digraphs.


Oh - so many different ways to do things, all interesting, and all 
good for some variation of the problem.



btw - that reminds me - back when I used to play real, physical Boggle 
with friends, we often played variants of the word rules; either


 - you can reuse the same tile later in a word (e.g.
Y  L  A
X  E  T

would allow "lately" as a word.

OR

- you can double-up on a tile (e.g. M I L would allow 'mill')
(more important if you're British than if you're American :-)

Alex.



___
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


___
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

Re: Speed up a slow loop

[Alex Tweedly via use-livecode]

Yes, Quentin's allowing for diagonals (that's how the number of digraphs 
on a 5x5 board gets up to 110).


And it's probably a good idea, allowing an even finer filter - if you 
aren't doing the boardwalk method..


If you do use the boardwalk to generate the exact list of words, you get 
no benefit from single-letter or digraph filtering, because the 
tree-walk is constrained to only those valid "next char"s, and so 
implicitly avoids using those non-present digraphs.


Oh - so many different ways to do things, all interesting, and all good 
for some variation of the problem.



btw - that reminds me - back when I used to play real, physical Boggle 
with friends, we often played variants of the word rules; either


 - you can reuse the same tile later in a word (e.g.
Y  L  A
X  E  T

would allow "lately" as a word.

OR

- you can double-up on a tile (e.g. M I L would allow 'mill')
(more important if you're British than if you're American :-)

Alex.



___
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

I'm not sure I followed all that, but did you account for diagonals? It sounds like you'd need 
to calculate all the possible polygons in a 5x5 grid, starting from anywhere, and sometimes 
wrapping around itself.


I don't have the math skills to do that but when I get this thing presentable you could take a 
look and see what you think.



On 3/8/22 8:32 PM, Quentin Long via use-livecode wrote:

It occurs to me that any word which is valid in Boggle must consist of an 
uninterrupted run of letters which are *right next to each other* on the board. 
Hence, any digraph which *doesn't* consist of a pair of neighboring letters, 
*cannot* occur in any valid word.
Since the "filter out all words with LettersNotOnTheBoard" idea worked, it may be that an 
analogous "filter out" operation can speed things up more. When setting up a new board...
-- Construct a list of all 576 ( = 26x26 ) digraphs—"aa,ab,ac, … zx,zy,zz". Or, more likely, 
construct that list ahead of time, and store the list in a stack property.-- Remove all digraphs which 
contain at least one letter that's not on the board.-- Make a list of all pairs of neighboring letters on the 
board. Since you don't know which direction an arbitrary digraph is running in, you'll want to include ZA as 
well as AZ.-- Remove all the digraphs present on the board from the ListOfAllDigraphs.-- Replace all the 
"," in the ListOfAllDigraphs with "|". (i.e., replace commas with pipes)
-- Put "[" & ListOfAllAbsentDigraphs & "]" into RegexPattern.-- Filter WordList 
without RegexPattern.-- ???-- Profit.
Hmmm... since this starts out with a complete list of all 576 digraphs, there's 
no need to do a separate regex filter on individual letters; filtering out the 
full list of unused digraphs should encompass filtering out unused letters. 
Hence, just one regex filter should do the job. I think.
On a 4x4 Boggle board, there are 72 neighboring pairs, hence a maximum of 144 
valid digraphs; on a 5x5 board, there are 110 neighing pairs, hence a max of 
220 digraphs. Hopefully, this won't add too much overhead to board setup.

"Bewitched" + "Charlie's Angels" - Charlie = "At Arm's Length" Read the webcomic at [ 
http://www.atarmslength.net ]! If you like "At Arm's Length", support it at [ 
http://www.patreon.com/DarkwingDude ].
___
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



--
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/8/22 5:56 PM, Neville Smythe via use-livecode wrote:

reducing the list to around 20K words evidently removes the issue, which 
suggests multiple copies of the array are being created somewhere in (Jacque’s 
original ) search algorithm.


Yeah, I was keeping two copies without realizing it. Once I cleared unused variables I was able 
to reduce the amount of RAM being used by about 5MB.


--
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

Re: Speed up a slow loop

[Bob Sneidar via use-livecode]

Hmmm... I think I misread you to say that arrays are indexed. If that were the 
case, then the devs *should* be able to create functions for querying them and 
getting a subset of keys. I think then that this is NOT the case. 

Bob S


> On Mar 9, 2022, at 07:57 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Then why isn't there a method to query an array? That was precicely why I 
> wrote the routines to convert an array to a database. 
> 
> Bob S
> 
> 
>> On Mar 8, 2022, at 15:56 , Neville Smythe via use-livecode 
>>  wrote:
>> 
>> Turning the list into an array will add indexing overhead very similar to 
>> what using a database would do (I suspect extremely similar in fact!)


___
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

Re: Speed up a slow loop

[Bob Sneidar via use-livecode]

Then why isn't there a method to query an array? That was precicely why I wrote 
the routines to convert an array to a database. 

Bob S


> On Mar 8, 2022, at 15:56 , Neville Smythe via use-livecode 
>  wrote:
> 
> Turning the list into an array will add indexing overhead very similar to 
> what using a database would do (I suspect extremely similar in fact!)


___
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

Re: Speed up a slow loop

[Quentin Long via use-livecode]

It occurs to me that any word which is valid in Boggle must consist of an 
uninterrupted run of letters which are *right next to each other* on the board. 
Hence, any digraph which *doesn't* consist of a pair of neighboring letters, 
*cannot* occur in any valid word.
Since the "filter out all words with LettersNotOnTheBoard" idea worked, it may 
be that an analogous "filter out" operation can speed things up more. When 
setting up a new board...
-- Construct a list of all 576 ( = 26x26 ) digraphs—"aa,ab,ac, … zx,zy,zz". Or, 
more likely, construct that list ahead of time, and store the list in a stack 
property.-- Remove all digraphs which contain at least one letter that's not on 
the board.-- Make a list of all pairs of neighboring letters on the board. 
Since you don't know which direction an arbitrary digraph is running in, you'll 
want to include ZA as well as AZ.-- Remove all the digraphs present on the 
board from the ListOfAllDigraphs.-- Replace all the "," in the 
ListOfAllDigraphs with "|". (i.e., replace commas with pipes)
-- Put "[" & ListOfAllAbsentDigraphs & "]" into RegexPattern.-- Filter WordList 
without RegexPattern.-- ???-- Profit.
Hmmm... since this starts out with a complete list of all 576 digraphs, there's 
no need to do a separate regex filter on individual letters; filtering out the 
full list of unused digraphs should encompass filtering out unused letters. 
Hence, just one regex filter should do the job. I think.
On a 4x4 Boggle board, there are 72 neighboring pairs, hence a maximum of 144 
valid digraphs; on a 5x5 board, there are 110 neighing pairs, hence a max of 
220 digraphs. Hopefully, this won't add too much overhead to board setup.

"Bewitched" + "Charlie's Angels" - Charlie = "At Arm's Length" Read the 
webcomic at [ http://www.atarmslength.net ]! If you like "At Arm's Length", 
support it at [ http://www.patreon.com/DarkwingDude ].
___
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

Re: Speed up a slow loop

[Neville Smythe via use-livecode]

> On 9 Mar 2022, at 4:00 am, Alex Tweedly wrote:
> 
> I guess I'm not convinced about VM space thrashing being the problem, 
> certainly not due to the wordlist. It's 2.5 Mb - i.e. 0.02% of the real 
> RAM in a Pixel 5. There may be something else in the app making the 
> total VM space very large - but the wordlist wouldn't do it on its own.

I have to agree … although the relevant RAM size is the amount allocated to the 
app, not the total RAM. The OS presumably takes up most of the RAM by itself. 
But of course just a single copy of the list in memory is not a problem or 
Jacque wouldn’t be able to do the filtering.  Turning the list into an array 
will add indexing overhead very similar to what using a database would do (I 
suspect extremely similar in fact!) but I would have thought we are still only 
talking 10MB at most. Possibly more, the faster-than-light magic that happens 
with arrays must be trading off memory for cpu time somehow  The symptoms 
definitely sound to me like VM thrashing, and reducing the list to around 20K 
words evidently removes the issue, which suggests multiple copies of the array 
are being created somewhere in (Jacque’s original ) search algorithm.
> 
> 
>> An alternative is to use an sqlite database, always an option which should 
>> be considered when handling large data. This completely removes the issue of 
>> having the wordlist in memory, and at the same time provides an extremely 
>> fast search engine, so was worth exploring as a solution to both problems. 
>> Storing the words in a db single table with an index on initial letter and 
>> word length, or as lots of tables, one for each initial and length (!), both 
>> return a result for a search for a word in a small fraction of a 
>> millisecond, so definitely this would be a viable solution which would 
>> handle all letter distributions.
> Sounds cool. I'd like to see an example of how this would be created and 
> used (I'm very much a SQL novice).

I can’t claim to be an expert myself (see below) but it’s not hard and the LC 
tutorial together with online sqlite cheat sheets make it pretty 
straightforward. The hardest bit is getting into the db mindset which a bit 
different from procedural coding. The LC library makes it very easy to use 
sqlite in stacks. Creating the db from the data is easy,  it only needs some 
thought on what tables and columns are needed - just like designing a DataGrid 
in LC. Making simple queries of the db is plain language-like. For example to  
find all words matching a crossword pattern - - T - - - -  containing N you 
execute a query such as

SELECT FROM words WHERE (length=7) AND (word LIKE ‘__T’) AND (word LIKE 
‘%N%’);

[ wildcard underscore _ matches a single character, % matches an arbitrary 
string … sound familiar? LIKE is used for comparing strings]

This outputs the 89 answers in a few milliseconds [most of which look to me 
like real words. But LETTERN ?? WITCHEN ?? SOWPODS really is ridiculous]

Making more complex queries is where things get arcane.

>> There is however a downside: both methods produce a db file size of 7.1 MB 
>> for the SOWPODS wordlist, which rather bloats the app footprint, even when 
>> you discount the text file version of the wordlist which no longer needs to 
>> be stored.
> You could do the opposite. Store the wordlist (700Kb compressed), and 
> decompress/populate into the SQLite database on initial run.

But unfortunately populating the database is very slow, taking minutes. [Note 
to myself: hey wait a minute, me, a database with only 275K rows is not that 
big in sqlite terms. Why is it taking so long? Because I am using a dumb repeat 
loop inserting one word at a time, akin to adding one word at a time to a field 
and then updating the UI. There is a better way. Physician, heal thyself!]

>> But now, speaking of databases, I have a question. I have an update to my 
>> nsScriptDatabase stack which I want to upload to the Sample Stacks. Because 
>> it really should be compiled to a standalone, I really need to upload a pair 
>> of stacks, a launch stack and one to hold data which can one modified by the 
>> user. But it would seem a sample stack must be a single item. What to do?
> 
> Yep -this is a big drawback of the Sample Stacks system.
> 
> Maybe you could make a single app, which contains the two desired stacks 
> as custom props.

Ah thank you, and a very interesting approach which I would never have thought 
of. Prompted me to think of another way: include the data stack as a substack 
when used in the IDE, but on openstack when not in the development environment 
clone the data stack to a writeable directory. That should work.

Neville

___
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/8/22 3:22 PM, Quentin Long via use-livecode wrote:

Does it*matter*  whether a genuine word isn't on the board? If the board has no "L" in 
it, any word with an "L" won't be on the board, right?


Right, but what happens is that your eye tricks you and you skip a tile inadvertently or use 
the same one twice. In Boggle, words are only valid if the tiles touch consecutively, and you 
can only use a particular tile once per word. So it's easy to use the same "e" twice, or to 
skip a tile to get to an "e".


Don't believe everything you (think) you see.

--
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

Re: Speed up a slow loop

[Neville Smythe via use-livecode]

> On 9 Mar 2022, at 4:00 am,Alex Tweedly wrote:
> 
> Oh, well, if you've got the fast boardwalk code in there anyway, that 
> opens up another possibility (with one caveat).
> 
> The boardwalk will find all valid words on the board. So that list of 
> words can be used as the "dictionary" for the user's guesses - and now 
> you have a "dictionary" of only a few hundred words, rather than than 
> the many thousands of either the original or the filtered dictionaries.
> 
Really only a few hundred potential words? My back-of-a-very-small-envelope 
guesstimate was about 2000.
I’ll be interested to see how many there are, because my envelope isn’t big 
enough to work it out, and the walking algorithm which I am really impressed 
can be so fast.

But anyway checking even a few hundred potential words (the vast majority of 
which would be non-words so the worst case) is going to be slower than checking 
a much smaller number of mostly valid user candidates. Both can one done in 
idle time so not a problem I guess.

Neville
___
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

Re: Speed up a slow loop

[Quentin Long via use-livecode]

sez Alex Tweedly:> The caveat - a user guess which isn't in the word list found 
by the > boardwalk can be either "not a word" or "a word, but not present on 
the 
> board", and you don't know which.
Does it *matter* whether a genuine word isn't on the board? If the board has no 
"L" in it, any word with an "L" won't be on the board, right?

"Bewitched" + "Charlie's Angels" - Charlie = "At Arm's Length" Read the 
webcomic at [ http://www.atarmslength.net ]! If you like "At Arm's Length", 
support it at [ http://www.patreon.com/DarkwingDude ].
___
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/8/22 1:27 AM, Neville Smythe via use-livecode wrote:

Jacque seems to have found a satisfactory solution to her problem with the help 
of the excellent suggestions we have seen here. Since there seems to have been 
a lot of interest, I thought I would take the opportunity to report on an 
alternative method I had been exploring with Jacque via email.


And it was appreciated. Neville and I had an off-list conversation where he really put some 
effort into solving the problem. In the long run I decided it would be better to keep 
everything in LCS if possible since the timings were fixed, but his help was one more example 
of how great our community is.


--
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/8/22 10:30 AM, Alex Tweedly via use-livecode wrote:
I guess I'm not convinced about VM space thrashing being the problem, certainly not due to the 
wordlist. It's 2.5 Mb - i.e. 0.02% of the real RAM in a Pixel 5. There may be something else in 
the app making the total VM space very large - but the wordlist wouldn't do it on its own.


I'm not sure either. A few days ago I did some tests trying to track the total amount of RAM 
that was used by looking at the memory stats in the developer options. I started the game, did 
some quick word lookups, quit and removed from memory, then checked usage. It isn't very 
specific but while my app was running the Pixel 6 had a maximum usage of 368MB after three 
tests, and the Pixel 5 maxed at 255MB. This isn't near the top of the list, other apps use more.


On the Pixel 5 today, with only background apps running, I'm using 55% of RAM which leaves 
3.5GB free. The Pixel 6 is using 70% with 2.4GB free. The OS on the 6 is bigger and I have more 
background processes running there.


In trying to reduce the memory footprint I wanted to see how much RAM my script locals were 
storing. The easiest way was to get the value of all of them, write them consecutively to a 
file, and let Finder tell me the size. I found that Alex's brilliant script was holding 5MB of 
data that I didn't need, so I emptied out the variables that were only used to calculate the 
board and kept the single one I needed for lookups. That file was 3K.


I need to test more today. Last night I thought I was all set, got a great board and quickly 
found 125 words. Everything was snappy and worked great. Then suddenly the app froze solid, 
nothing responded, and I had to quit to the launcher. Which was a shame because it was a really 
good board. That was before I wiped out the extra 5MB of unnecessary variable data, and there 
may be more I can do trim it down. But you'd think 2-3GB of free RAM could accomodate it.


If I can't figure it out soon, I'll give it to all of you to see if you can.

--
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

Re: Speed up a slow loop

[Alex Tweedly via use-livecode]

On 08/03/2022 07:27, Neville Smythe via use-livecode wrote:

I believe there were two problems: a) the original search search algorithm was 
too slow, and b) when implemented on certain devices the app went into an 
unusable state. Both problems were caused by the wordlist being stored being 
too large (275K words for a file size of  2.5 MB). The second issue we are 
pretty sure was Virtual Memory swap space thrashing.


I guess I'm not convinced about VM space thrashing being the problem, 
certainly not due to the wordlist. It's 2.5 Mb - i.e. 0.02% of the real 
RAM in a Pixel 5. There may be something else in the app making the 
total VM space very large - but the wordlist wouldn't do it on its own.




An alternative is to use an sqlite database, always an option which should be 
considered when handling large data. This completely removes the issue of 
having the wordlist in memory, and at the same time provides an extremely fast 
search engine, so was worth exploring as a solution to both problems.  Storing 
the words in a db single table with an index on initial letter and word length, 
or as lots of tables, one for each initial and length (!), both return a result 
for a search for a word in a small fraction of a millisecond, so definitely 
this would be a viable solution which would handle all letter distributions.
Sounds cool. I'd like to see an example of how this would be created and 
used (I'm very much a SQL novice).

There is however a downside: both methods produce a db file size of 7.1 MB for 
the SOWPODS wordlist, which rather bloats the app footprint, even when you 
discount the text file version of the wordlist which no longer needs to be 
stored.
You could do the opposite. Store the wordlist (700Kb compressed), and 
decompress/populate into the SQLite database on initial run.

But now, speaking of databases, I have a question. I have an update to my 
nsScriptDatabase stack which I want to upload to the Sample Stacks. Because it 
really should be compiled to a standalone, I really need to upload a pair of 
stacks, a launch stack and one to hold data which can one modified by the user. 
But it would seem a sample stack must be a single item. What to do?


Yep -this is a big drawback of the Sample Stacks system.

Maybe you could make a single app, which contains the two desired stacks 
as custom props.


(Sometimes it's easier to type code than to describe it :-)
In your preparation, you'd do:
 put URL ("binfile:launchstack.livecode") into tmp
 set the cLaunch of me to compress(tmp)
 put URL ("binfile:userdatastack.livecode") into tmp
 set the cUser of me to compress(tmp)

And then when the user downloads your sample stack, it does the inverse 
to create the two local stacks, with an info box telling them about it.


Alex.

___
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

Re: Speed up a slow loop

[Mark Smith via use-livecode]

Apart from searching I am sure it will provide many other great learning 
opportunities as well. Looking forward to seeing how it all pans out. 

Mark

> On Mar 6, 2022, at 8:18 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> On 3/6/22 9:40 AM, William Prothero via use-livecode wrote:
>> I've been following this thread in wonder at the creative ways of optimizing 
>> this word search. I hope that the code will be published somewhere, 
>> available to all, with credits to the multiple idea authors.
> 
> I can upload it to Sample Stacks when it's done, there's nothing proprietary 
> about it. There's no point to submitting it to any of the app stores since 1) 
> the name "Boggle" is copyrighted as well as the game itself, and 2) there are 
> a gazillion word search games there anyway.
> 
> I wrote it for myself and anyone else who wants to play with it.
> 
> -- 
> 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


___
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

Re: Speed up a slow loop

[Neville Smythe via use-livecode]

Jacque seems to have found a satisfactory solution to her problem with the help 
of the excellent suggestions we have seen here. Since there seems to have been 
a lot of interest, I thought I would take the opportunity to report on an 
alternative method I had been exploring with Jacque via email.

I believe there were two problems: a) the original search search algorithm was 
too slow, and b) when implemented on certain devices the app went into an 
unusable state. Both problems were caused by the wordlist being stored being 
too large (275K words for a file size of  2.5 MB). The second issue we are 
pretty sure was Virtual Memory swap space thrashing. 

Using Quentin’s why-didn’t-I-think-of-that filtering suggestion the wordlist 
can be reduced (in the vasty majority of cases) to a manageable size, say 20K 
words or less, and both problems solved very elegantly.

There are however edge cases where the filtered wordlist can still be huge, 
over 200K words, [ eg unused letters are JQXYZ  ]. Such cases are going to be 
very rare, so Jacque is going with the above solution. 

An alternative is to use an sqlite database, always an option which should be 
considered when handling large data. This completely removes the issue of 
having the wordlist in memory, and at the same time provides an extremely fast 
search engine, so was worth exploring as a solution to both problems.  Storing 
the words in a db single table with an index on initial letter and word length, 
or as lots of tables, one for each initial and length (!), both return a result 
for a search for a word in a small fraction of a millisecond, so definitely 
this would be a viable solution which would handle all letter distributions.

There is however a downside: both methods produce a db file size of 7.1 MB for 
the SOWPODS wordlist, which rather bloats the app footprint, even when you 
discount the text file version of the wordlist which no longer needs to be 
stored. If one was writing a crossword app, where you might be searching for 
words for which you know the 3rd and fifth letter for example, bread and butter 
for an sqlite query, this would definitely be the way to go, but probably 
overkill for Jacque’s app.

But now, speaking of databases, I have a question. I have an update to my 
nsScriptDatabase stack which I want to upload to the Sample Stacks. Because it 
really should be compiled to a standalone, I really need to upload a pair of 
stacks, a launch stack and one to hold data which can one modified by the user. 
But it would seem a sample stack must be a single item. What to do?

Neville
___
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/7/22 12:30 PM, Alex Tweedly via use-livecode wrote:


The boardwalk will find all valid words on the board. So that list of words can be used as the 
"dictionary" for the user's guesses - and now you have a "dictionary" of only a few hundred 
words, rather than than the many thousands of either the original or the filtered dictionaries.


And it's worth saying that the fast boardwalk only explores those potential words that are on 
the board, so there's no need to filter the dictionary for it.


The caveat - a user guess which isn't in the word list found by the boardwalk can be either 
"not a word" or "a word, but not present on the board", and you don't know which. If your UI 
needs to distinguish between those cases, you'd need to do another step of checking these 
(hopefully very few) failure cases against the full dictionary.


Wow, that's something else that didn't occur to me. I do, of course, have the word list from 
your board walk. At present I use it to provide a hint on demand if the user gets stuck. It's 
cheating, but hey, this is a one-person game and you're only cheating yourself. Nobody says you 
have to click that button.


I do need to discriminate between non-words and words not on the board, but the dictionary 
check is now so fast that it isn't a problem. The most time-consuming part is now the 
boardwalk, but it will be instant when I check the word list your script creates.


Have you heard the joke about how a camel is a horse created by a committee? That's not always 
true. This game is getting better and better.


--
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

Re: Speed up a slow loop

[Alex Tweedly via use-livecode]

On 06/03/2022 22:56, J. Landman Gay via use-livecode wrote:


The board walk took 179 ms for all 108 words because I ditched my old, 
juvenile, inefficient code and swiped yours. :) As Bill requested, 
I've marked all the stuff I used with credits for the people who 
suggested or provided code, so you're in there. The two most impactful 
changes were your board walk and Quentin's filtered dictionary idea, 
but there are also other improvements.


Oh, well, if you've got the fast boardwalk code in there anyway, that 
opens up another possibility (with one caveat).


The boardwalk will find all valid words on the board. So that list of 
words can be used as the "dictionary" for the user's guesses - and now 
you have a "dictionary" of only a few hundred words, rather than than 
the many thousands of either the original or the filtered dictionaries.


And it's worth saying that the fast boardwalk only explores those 
potential words that are on the board, so there's no need to filter the 
dictionary for it.


The caveat - a user guess which isn't in the word list found by the 
boardwalk can be either "not a word" or "a word, but not present on the 
board", and you don't know which. If your UI needs to distinguish 
between those cases, you'd need to do another step of checking these 
(hopefully very few) failure cases against the full dictionary.


Alex.


___
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

Re: Speed up a slow loop

[Bob Sneidar via use-livecode]

You people are too smart for me. 

Sent from my iPhone

> On Mar 6, 2022, at 07:41, William Prothero via use-livecode 
>  wrote:
> 
> Folks:
> I've been following this thread in wonder at the creative ways of optimizing 
> this word search. I hope that the code will be published somewhere, available 
> to all, with credits to the multiple idea authors.
> 
> Kudos and congratulations to those who offered such creative and thoughtful 
> ideas. I'm awed!
> 
> Bill
> 
> William A. Prothero, PhD
> Prof Emeritus, Dept of Earth Science
> University of California, Santa Barbara
> 
>> On Mar 6, 2022, at 5:33 AM, Alex Tweedly via use-livecode 
>>  wrote:
>> 
>> 
>>>> On 06/03/2022 06:35, J. Landman Gay via use-livecode wrote:
>>> 
>>> Combined with Ken's suggestion to use "difference", looking up a list of 
>>> about 50 words in the filtered dictionary reduces the time from 2-4 seconds 
>>> to about 40 ms. It varies, depending on a lot of things, but it's fast 
>>> enough that you don't notice. That's on my Pixel 5; on the Mac a lookup 
>>> takes 5ms. And I can do it all in LC script.
>>> 
>> 5ms !?!
>> 
>> I did a (very simple) test  (see code below)
>> 
>> - take the whole sowpods.txt file (267k words)
>> 
>> - create a set (i.e. split by CR as set)
>> 
>> - look up 50 randomly chosen words + 5 non-words (just in case failed 
>> searches were expensive).
>> 
>> Doing this 100 times takes 6-10 ms (on an old MacBook Pro).
>> 
>> Could you maybe post the code that you're using that takes 5ms ?
>> 
>>> I love these little speed contests we have here. Thank you.
>>> 
>> Alex.
>> 
>>> 
>>> on mouseup
>>>   local tmp, tNumberOfLines, tNumberOfLoops
>>>   local tWords, tAWords, tTries
>>> 
>>>   put the cWords of me into tWords
>>>   if tWords is empty then
>>>  put URL ("file:" & specialfolderpath("resources") & "/sowpods.txt") 
>>> into tWords
>>>  set the cwords of me to tWords
>>>  put "From file" &CR into fld "F"
>>>   else
>>>  put "using custom property" &CR into fld "F"
>>>   end if
>>> 
>>>   put tWords into tAWords
>>>   split tAWords by CR as set
>>> 
>>>   repeat with I = 1 to 50
>>>  put random(the number of lines in tWords) into tmp
>>>  put line tmp of tWords &CR after tTries
>>>   end repeat
>>>   repeat with I = 1 to 5
>>>  put "azazaz" &Cr after tTries
>>>   end repeat
>>> 
>>>   put 100 into tNumberofLoops
>>> 
>>>   local t1, t2, tCount, tTotal
>>> 
>>>   --   put the millisecs into t1
>>>   --   repeat tNumberOfLoops times
>>>   --  put 0 into tCount
>>>   --  repeat for each line L in tTries
>>>   -- if L is among the lines of tWords then add 1 to tCount
>>>   --  end repeat
>>>   --   end repeat
>>>   --   put the millisecs into t2
>>>   --   put tCOunt && "iterate lines" && t2-t1 &CR after fld "F"
>>> 
>>>   put the millisecs into t1
>>>   repeat tNumberOfLoops times
>>>  put 0 into tCount
>>>  put 0 into tTotal
>>>  repeat for each line L in tTries
>>> add 1 to tTotal
>>> if tAWords[L] then add 1 to tCount
>>>  end repeat
>>>   end repeat
>>>   put the millisecs into t2
>>>   put tCount && "of" && tTotal && "each element" && t2-t1 &CR after fld "F"
>>> 
>>> 
>>> end mouseup
>> 
>> 
>> ___
>> 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
> 
> 
> ___
> 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
___
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/6/22 1:43 PM, Alex Tweedly via use-livecode wrote:
Another thought on this problem; I think worth discussing even if the various suggestions so 
far have already got you a solution. I think it's a general observation ...


You don't really care how long it takes to do this.
What you care about is how long the user has to wait for your (the app's) 
response.

So don't wait until the user has found all their possible words (i.e. the app is doing 
effectively nothing for the 30 seconds or so that the user gets for each board). Check each 
word as they type it, and store the result. Then, when the 30-sec timer is up, you will have 
only one or two last words to test - all the others have already been checked.


So you never care about how long it takes to check 50 or so words against the dictionary - you 
check 49 of them one-at-a-time during the time you are otherwise idle. And the user has only to 
wait for the negligible delay while you check one or two words.


Good point for later. I was just testing on my Pixel 5, which was slow as hell before, and it 
just verified and marked up a user list of 108 words in 0 ms. I'm astonished at what we've done 
here. The longest word list I've been able to produce has about 225 words, so if it takes an 
extra ms I'm okay with that.


If it ain't broke...

The board walk took 179 ms for all 108 words because I ditched my old, juvenile, inefficient 
code and swiped yours. :) As Bill requested, I've marked all the stuff I used with credits for 
the people who suggested or provided code, so you're in there. The two most impactful changes 
were your board walk and Quentin's filtered dictionary idea, but there are also other improvements.


The one thing I still dont understand is why responses were so fast on my old Android tablet 
before I made changes. It's happy with the new code but there's little discernable difference 
in response time.


--
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

Re: Speed up a slow loop

[Dick Kriesel via use-livecode]

> On Mar 2, 2022, at 1:57 PM, J. Landman Gay via use-livecode 
>  wrote:
> ...
> repeat for each line l in pList -- pList is the user word list
>if sDictFile[l] = true then put l & cr after tCheckedList
>else put l & cr after tNonWords
>wait 0 with messages  -- prevent ANRs
>  end repeat
>  …

Hi, Jacque. If you use sets of words, as sDictFile already is, and as Ken 
suggested, then you can eliminate the repeat loop:


split pList by cr into tUserWords
intersect tUserWords with sDictFile into tChecked
difference tUserWords with sDictFile into tNonWords


Does that turn out to be fast enough for you?

— Dick


___
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/6/22 9:40 AM, William Prothero via use-livecode wrote:

I've been following this thread in wonder at the creative ways of optimizing 
this word search. I hope that the code will be published somewhere, available 
to all, with credits to the multiple idea authors.


I can upload it to Sample Stacks when it's done, there's nothing proprietary about it. There's 
no point to submitting it to any of the app stores since 1) the name "Boggle" is copyrighted as 
well as the game itself, and 2) there are a gazillion word search games there anyway.


I wrote it for myself and anyone else who wants to play with it.

--
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/6/22 7:33 AM, Alex Tweedly via use-livecode wrote:

Could you maybe post the code that you're using that takes 5ms ?


It does a bit more than your test, and I only estimated the number of user words since I'd 
tried so many things. I just tested again and this list has 173 words. The dictionary array has 
been reduced as per Quentin's suggestion.


I need to get two lists, one for correct words and another for incorrect words. I used to hit 
the array directly but my current method uses the difference command. Here's the lookup I'm 
using, sDictFile is a script local array:


function checkDictionary pList -- check dictionary for valid words
  put empty into tNonWords
  split pList by cr and tab
  difference pList with sDictFile into tNonWords

  set wholematches to true
  put fld "wordList" into tWList -- no longer the same as pList
  lock screen
  repeat for each key k in tNonWords -- mark non-words in list
set the textcolor of word 1 of line lineoffset(k,tWList) of fld "wordList" to 
"red"
  end repeat
  unlock screen
  if tNonWords <> "" then put keys(tNonWords) into sStats["unknowns"] -- stats 
for reporting later

  difference pList with tNonWords
  return keys(pList)
end checkDictionary

I thought the extra time might be due to the field updates, but when I added 8 incorrect words 
the time didn't change. It remains steady at 5ms.


So I switched back to hitting the dictionary array directly, and the time for 173 valid words 
and 8 invalid words dropped (on Mac) to 1. :)


function checkDictionary pList -- check dictionary for valid words
  set wholematches to true
  repeat for each line l in pList
if sDictFile[l] = true then
  put l & cr after tValidWords
else
  put l & cr after tNonWords
end if
  end repeat
  lock screen
  repeat for each line l in tNonWords -- mark non-words in list
set the textcolor of word 1 of line lineoffset(l,pList) of fld "wordList" to 
"red"
  end repeat
  unlock screen
  if tNonWords <> "" then put tNonWords into sStats["unknowns"]
  return tValidWords
end checkDictionary

So there you have it. I'll go back to the original method. I'm glad you 
questioned this.


--
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

Re: Speed up a slow loop

[Alex Tweedly via use-livecode]

Another thought on this problem; I think worth discussing even if the 
various suggestions so far have already got you a solution. I think it's 
a general observation ...


You don't really care how long it takes to do this.
What you care about is how long the user has to wait for your (the 
app's) response.


So don't wait until the user has found all their possible words (i.e. 
the app is doing effectively nothing for the 30 seconds or so that the 
user gets for each board). Check each word as they type it, and store 
the result. Then, when the 30-sec timer is up, you will have only one or 
two last words to test - all the others have already been checked.


So you never care about how long it takes to check 50 or so words 
against the dictionary - you check 49 of them one-at-a-time during the 
time you are otherwise idle. And the user has only to wait for the 
negligible delay while you check one or two words.



Alex.


___
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

Re: Speed up a slow loop

[William Prothero via use-livecode]

Folks:
I've been following this thread in wonder at the creative ways of optimizing 
this word search. I hope that the code will be published somewhere, available 
to all, with credits to the multiple idea authors.

Kudos and congratulations to those who offered such creative and thoughtful 
ideas. I'm awed!

Bill

William A. Prothero, PhD
Prof Emeritus, Dept of Earth Science
University of California, Santa Barbara

> On Mar 6, 2022, at 5:33 AM, Alex Tweedly via use-livecode 
>  wrote:
> 
> 
>> On 06/03/2022 06:35, J. Landman Gay via use-livecode wrote:
>> 
>> Combined with Ken's suggestion to use "difference", looking up a list of 
>> about 50 words in the filtered dictionary reduces the time from 2-4 seconds 
>> to about 40 ms. It varies, depending on a lot of things, but it's fast 
>> enough that you don't notice. That's on my Pixel 5; on the Mac a lookup 
>> takes 5ms. And I can do it all in LC script.
>> 
> 5ms !?!
> 
> I did a (very simple) test  (see code below)
> 
>  - take the whole sowpods.txt file (267k words)
> 
>  - create a set (i.e. split by CR as set)
> 
>  - look up 50 randomly chosen words + 5 non-words (just in case failed 
> searches were expensive).
> 
> Doing this 100 times takes 6-10 ms (on an old MacBook Pro).
> 
> Could you maybe post the code that you're using that takes 5ms ?
> 
>> I love these little speed contests we have here. Thank you.
>> 
> Alex.
> 
>> 
>> on mouseup
>>local tmp, tNumberOfLines, tNumberOfLoops
>>local tWords, tAWords, tTries
>> 
>>put the cWords of me into tWords
>>if tWords is empty then
>>   put URL ("file:" & specialfolderpath("resources") & "/sowpods.txt") 
>> into tWords
>>   set the cwords of me to tWords
>>   put "From file" &CR into fld "F"
>>else
>>   put "using custom property" &CR into fld "F"
>>end if
>> 
>>put tWords into tAWords
>>split tAWords by CR as set
>> 
>>repeat with I = 1 to 50
>>   put random(the number of lines in tWords) into tmp
>>   put line tmp of tWords &CR after tTries
>>end repeat
>>repeat with I = 1 to 5
>>   put "azazaz" &Cr after tTries
>>end repeat
>> 
>>put 100 into tNumberofLoops
>> 
>>local t1, t2, tCount, tTotal
>> 
>>--   put the millisecs into t1
>>--   repeat tNumberOfLoops times
>>--  put 0 into tCount
>>--  repeat for each line L in tTries
>>-- if L is among the lines of tWords then add 1 to tCount
>>--  end repeat
>>--   end repeat
>>--   put the millisecs into t2
>>--   put tCOunt && "iterate lines" && t2-t1 &CR after fld "F"
>> 
>>put the millisecs into t1
>>repeat tNumberOfLoops times
>>   put 0 into tCount
>>   put 0 into tTotal
>>   repeat for each line L in tTries
>>  add 1 to tTotal
>>  if tAWords[L] then add 1 to tCount
>>   end repeat
>>end repeat
>>put the millisecs into t2
>>put tCount && "of" && tTotal && "each element" && t2-t1 &CR after fld "F"
>> 
>> 
>> end mouseup
> 
> 
> ___
> 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


___
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

Re: Speed up a slow loop

[Alex Tweedly via use-livecode]

On 06/03/2022 06:35, J. Landman Gay via use-livecode wrote:


Combined with Ken's suggestion to use "difference", looking up a list 
of about 50 words in the filtered dictionary reduces the time from 2-4 
seconds to about 40 ms. It varies, depending on a lot of things, but 
it's fast enough that you don't notice. That's on my Pixel 5; on the 
Mac a lookup takes 5ms. And I can do it all in LC script.



5ms !?!

I did a (very simple) test  (see code below)

 - take the whole sowpods.txt file (267k words)

 - create a set (i.e. split by CR as set)

 - look up 50 randomly chosen words + 5 non-words (just in case failed 
searches were expensive).


Doing this 100 times takes 6-10 ms (on an old MacBook Pro).

Could you maybe post the code that you're using that takes 5ms ?


I love these little speed contests we have here. Thank you.


Alex.



on mouseup
   local tmp, tNumberOfLines, tNumberOfLoops
   local tWords, tAWords, tTries

   put the cWords of me into tWords
   if tWords is empty then
  put URL ("file:" & specialfolderpath("resources") & 
"/sowpods.txt") into tWords

  set the cwords of me to tWords
  put "From file" &CR into fld "F"
   else
  put "using custom property" &CR into fld "F"
   end if

   put tWords into tAWords
   split tAWords by CR as set

   repeat with I = 1 to 50
  put random(the number of lines in tWords) into tmp
  put line tmp of tWords &CR after tTries
   end repeat
   repeat with I = 1 to 5
  put "azazaz" &Cr after tTries
   end repeat

   put 100 into tNumberofLoops

   local t1, t2, tCount, tTotal

   --   put the millisecs into t1
   --   repeat tNumberOfLoops times
   --  put 0 into tCount
   --  repeat for each line L in tTries
   -- if L is among the lines of tWords then add 1 to tCount
   --  end repeat
   --   end repeat
   --   put the millisecs into t2
   --   put tCOunt && "iterate lines" && t2-t1 &CR after fld "F"

   put the millisecs into t1
   repeat tNumberOfLoops times
  put 0 into tCount
  put 0 into tTotal
  repeat for each line L in tTries
 add 1 to tTotal
 if tAWords[L] then add 1 to tCount
  end repeat
   end repeat
   put the millisecs into t2
   put tCount && "of" && tTotal && "each element" && t2-t1 &CR after 
fld "F"



end mouseup



___
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/5/22 8:36 PM, Quentin Long via use-livecode wrote:


When you create a new board:

-- Make a list of all the letters which *are not* on the board


-- Filter out any word that contains at least one letter on the "not on this 
board" list

-- Use the thus-reduced wordlist for all purposes as long as the board doesn't 
change

This would add a bit of overhead to the process of setting up a new board, but 
if it results in time savings during play, the extra overhead might be 
worthwhile anyway.


Clever. Why didn't I think of that?

I can create a new board, calculate all letters that don't exist on it, and filter out all 
dictionary words containing them in something like 170 ms. It doesn't impact the setup at all. 
It reduces the dictionary from 171,000+ words to around 20,000 give or take, depending on the 
current board distribution. On one board it reduced it to about 11,000 words.


Combined with Ken's suggestion to use "difference", looking up a list of about 50 words in the 
filtered dictionary reduces the time from 2-4 seconds to about 40 ms. It varies, depending on a 
lot of things, but it's fast enough that you don't notice. That's on my Pixel 5; on the Mac a 
lookup takes 5ms. And I can do it all in LC script.


I love these little speed contests we have here. Thank you.

--
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

Interesting idea. There are 25 letters on each board, some are always repeats. I think I'd need 
a good regex so I wouldn't have to run the filter command multiple times. How's your regex?


On the other hand, I suppose filtering out even just 2 or 3 letters might make a dent. I'll try 
that first.



On 3/5/22 8:36 PM, Quentin Long via use-livecode wrote:


So… a Boggle game. Hm. Seems to me that anything you can do to reduce the 
number of words you need consider at any given time would be a win. Maybe not a 
*big* win, but still a win. So perhaps give this idea a shot:

When you create a new board:

-- Make a list of all the letters which *are not* on the board


-- Filter out any word that contains at least one letter on the "not on this 
board" list

-- Use the thus-reduced wordlist for all purposes as long as the board doesn't 
change

This would add a bit of overhead to the process of setting up a new board, but 
if it results in time savings during play, the extra overhead might be 
worthwhile anyway.



--
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

Re: Speed up a slow loop

[Quentin Long via use-livecode]

So… a Boggle game. Hm. Seems to me that anything you can do to reduce the 
number of words you need consider at any given time would be a win. Maybe not a 
*big* win, but still a win. So perhaps give this idea a shot:

When you create a new board:

-- Make a list of all the letters which *are not* on the board


-- Filter out any word that contains at least one letter on the "not on this 
board" list

-- Use the thus-reduced wordlist for all purposes as long as the board doesn't 
change

This would add a bit of overhead to the process of setting up a new board, but 
if it results in time savings during play, the extra overhead might be 
worthwhile anyway.



"Bewitched" + "Charlie's Angels" - Charlie = "At Arm's Length" Read the 
webcomic at [ http://www.atarmslength.net ]! If you like "At Arm's Length", 
support it at [ http://www.patreon.com/DarkwingDude ].
___
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

Re: Speed up a slow loop

[Bob Sneidar via use-livecode]

Well… the idea was, if storing and working with the data as arrays was crucial, 
then I have a method for creating sqLite databases, memory or otherwise, from 
arrays and then back again. I don’t know if mobile devices can use memory 
databases, or perhaps the data is too much for mobile device limits, so I am 
sailing murky waters there. But once the overhead of iterating through the 
array once is spent, recursive querying of a memory or even a file database is 
much more efficient.  

Sent from my iPhone

> On Mar 4, 2022, at 15:16, Neville Smythe via use-livecode 
>  wrote:
> 
> Bob’s suggestion of storing the word list in an sqlite database would keep 
> the list on disk and not in memory
___
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/4/22 2:33 PM, Neville Smythe via use-livecode wrote:

Jacque, are you trying to keep the whole of SOWPODS in memory the whole time? 
That’s a 2.5MB file. It sounds to me like you are getting virtual memory 
thrashing.


I'm thinking the same thing, it's the only explanation. I stopped using SOWPODS and things got 
a bit faster after I substituted a file half that size.


I'm sure you and Bob are right about using a database, but I'm not a database person and I 
wouldn't know where to start. If anyone wants to help, you can have a free copy of my 
already-free game...


Probably we shouldn't cluter the list with that, but there's email.

--
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

Re: Speed up a slow loop

[Neville Smythe via use-livecode]

Bob’s suggestion of storing the word list in an sqlite database would keep the 
list on disk and not in memory, so avoiding VM swapping which is  I think  the 
basic problem, and also use a much faster search engine than LC to do the 
checking for the existence of user candidates. A more elegant solution than 
breaking up the wordlist into hundreds of small files. 

It is possible because we know the structure of the data in this case that lots 
of small files, with a couple of other tricks to reduce file size, and then 
using an LC search, could be faster (because the OS file system is even more 
efficient than sqlite) but I’d be surprised if the db approach didn’t solve 
your problem.


Neville
___
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

Re: Speed up a slow loop

[Neville Smythe via use-livecode]

Jacque, are you trying to keep the whole of SOWPODS in memory the whole time? 
That’s a 2.5MB file. It sounds to me like you are getting virtual memory 
thrashing.

If so, try breaking up the wordlist into 26 files for example - or even more by 
length as well as initial letter - kept as resources (rather than in fields)  
and only reading in the file required to check  a word as needed (and emptying 
the variable loaded from file asap). My guess is a linear search on a small 
file is going to be faster than array indexing magic if memory swapping starts 
to occur.

Neville
___
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

Re: Speed up a slow loop

[Bob Sneidar via use-livecode]

I am not sure if Android or MacOS can use sqLite memory databases, but when I 
need to iterate through a large array, I first convert the array to an sqLite 
memory database, then query it, which is a gazillion times faster than 
iterating through an array. 

I have functions which create an sqLite database from an array, then convert it 
back to an array again. 

Bob S


> On Mar 2, 2022, at 13:57 , J. Landman Gay via use-livecode 
>  wrote:
> 
> In my Boggle game I have an array containing dictionary words as keys, split 
> as set, so all values are "true". I need to compare those keys with a list of 
> user words and get back a list of good words and a list of illegal words.
> 
> The loop takes forever. Here it is (sDictFile is a script local):
> 
>  repeat for each line l in pList -- pList is the user word list
>if sDictFile[l] = true then put l & cr after tCheckedList
>else put l & cr after tNonWords
>wait 0 with messages  -- prevent ANRs
>  end repeat
> 
> I added the wait because my Android phone was putting up an "app not 
> responding" warning while the loop was running (or just after, hard to tell.) 
> The loop should be much faster than that. When I added some timing checks 
> though, the timer says the loop takes between 0 and 1 millisecond, and yet 
> the wait on screen remains.
> 
> With a 3-word user list, the loop takes 4 seconds. With an 8 word user list 
> the loop takes 6 seconds. The more user words, the longer the wait.
> 
> 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.
> 
> I've tried any number of workarounds without luck, on both LC 9.6.6 and LC 
> 10.0.0. Any ideas? I have a feeling it isn't the script per se, it's 
> something else.
> 
> -- 
> 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


___
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

Re: Speed up a slow loop

[Ken Ray via use-livecode]

BTW you an also use this "split" trick to remove dupes (although you lose the 
order of the word list):

function stripDupes pWordList
  split pWordList by cr and tab
  return (the keys of pWordList)
end stripDupes

on mouseUp
   put stripDupes("test" & cr & "ball" & cr & "test" & cr & "orange")
end mouseUp

Result:
ball
orange
test

Not sure if it's faster, but it may work in your situation,

Ken


> On Mar 3, 2022, at 2:28 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> 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

Ken Ray
Sons of Thunder Software, Inc.
Email: k...@sonsothunder.com
Website: https://www.sonsothunder.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

Re: Speed up a slow loop

[Ken Ray via use-livecode]

Jacque,

How about using the 'difference' command? Here's a simple example:


on mouseUp
   put "true" into tDict["test"]
   put "true" into tDict["word"]
   put "true" into tDict["ball"]
   
   put "test" & cr & "ball" & cr & "boat" & cr & "unicorn" into tUserWords

   split tUserWords by cr and tab
   difference tUserWords with tDict
   
   if tUserWords is not an array then
  answer "All words matched!"
   else
  answer "Sorry, try again, these words didn't match:" & cr & cr & (the 
keys of tUserWords)
   end if
end mouseUp

If you run this, it will say that "boat" and "unicorn" don't match; if 
tUserWords is "test" and "ball" you get "all words matched".

Will this work?


Ken



> On Mar 3, 2022, at 2:34 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> On 3/3/22 2:00 PM, Tom Glod via use-livecode wrote:
>> But what prevents you from loading all your data into an array?  and just
>> iterating over the keys or index of an array?  vs the lines of a long list.?
>> That will yield the fastest performance.
> 
> Right, it's an array, and I don't iterate. I just check the array key 
> directly for a value.
> 
> I realize I'm kind of monopolizing things here. I wrote the game for myself 
> and I ignored the speed issues and just played it on my tablet where it works 
> fine, but now someone else wants to include it in a distributed app so I need 
> to figure it out.
> 
> -- 
> 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

Ken Ray
Sons of Thunder Software, Inc.
Email: k...@sonsothunder.com
Website: https://www.sonsothunder.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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/3/22 2:00 PM, Tom Glod via use-livecode wrote:

But what prevents you from loading all your data into an array?  and just
iterating over the keys or index of an array?  vs the lines of a long list.?
That will yield the fastest performance.


Right, it's an array, and I don't iterate. I just check the array key directly 
for a value.

I realize I'm kind of monopolizing things here. I wrote the game for myself and I ignored the 
speed issues and just played it on my tablet where it works fine, but now someone else wants to 
include it in a distributed app so I need to figure it out.


--
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

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

Re: Speed up a slow loop

[Tom Glod via use-livecode]

This is a long thread and I can't read it at the moement,, and maybe you
have answered this.

But what prevents you from loading all your data into an array?  and just
iterating over the keys or index of an array?  vs the lines of a long list.?
That will yield the fastest performance.

I should have a full reda of the thread, there are always nuggets of gold
to be found :)

On Thu, Mar 3, 2022 at 8:37 AM Pi Digital via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I usually test this by using
>
> put the milliseconds into tMs
> …loop code…
> put the milliseconds - tMs
>
> This shows me a record of how long that loop took and helps me narrow down
> where the slow downs are occurring. You can do it within the loop too and
> keep a record for each iteration and see if it has a problem as it gets
> further down the list. But not likely with arrays.
>
> Sean Cole
> Pi Digital Productions Ltd
>
> eMail Ts & Cs
>
>
> > On 3 Mar 2022, at 06:53, Mark Waddingham via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > On 2022-03-02 21:57, J. Landman Gay via use-livecode wrote:
> >> The loop takes forever. Here it is (sDictFile is a script local):
> >>  repeat for each line l in pList -- pList is the user word list
> >>if sDictFile[l] = true then put l & cr after tCheckedList
> >>else put l & cr after tNonWords
> >>wait 0 with messages  -- prevent ANRs
> >>  end repeat
> >> I added the wait because my Android phone was putting up an "app not
> >> responding" warning while the loop was running (or just after, hard to
> >> tell.) The loop should be much faster than that. When I added some
> >> timing checks though, the timer says the loop takes between 0 and 1
> >> millisecond, and yet the wait on screen remains.
> >
> > 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).
> >
> >> With a 3-word user list, the loop takes 4 seconds. With an 8 word user
> >> list the loop takes 6 seconds. The more user words, the longer the
> >> wait.
> >
> > 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. Of course if the words are
> multiple megabytes long then it might be possible (however the timing you
> already stated above suggests the loop isn't actually taking 4 seconds!).
> >
> >> 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.
> >
> > Warmst Regards,
> >
> > Mark.
> >
> > --
> > Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> > LiveCode: Everyone can create apps
> >
> > ___
> > 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
> ___
> 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
>
___
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

Re: Speed up a slow loop

[Pi Digital via use-livecode]

I usually test this by using

put the milliseconds into tMs
…loop code…
put the milliseconds - tMs

This shows me a record of how long that loop took and helps me narrow down 
where the slow downs are occurring. You can do it within the loop too and keep 
a record for each iteration and see if it has a problem as it gets further down 
the list. But not likely with arrays. 

Sean Cole
Pi Digital Productions Ltd

eMail Ts & Cs


> On 3 Mar 2022, at 06:53, Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2022-03-02 21:57, J. Landman Gay via use-livecode wrote:
>> The loop takes forever. Here it is (sDictFile is a script local):
>>  repeat for each line l in pList -- pList is the user word list
>>if sDictFile[l] = true then put l & cr after tCheckedList
>>else put l & cr after tNonWords
>>wait 0 with messages  -- prevent ANRs
>>  end repeat
>> I added the wait because my Android phone was putting up an "app not
>> responding" warning while the loop was running (or just after, hard to
>> tell.) The loop should be much faster than that. When I added some
>> timing checks though, the timer says the loop takes between 0 and 1
>> millisecond, and yet the wait on screen remains.
> 
> 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).
> 
>> With a 3-word user list, the loop takes 4 seconds. With an 8 word user
>> list the loop takes 6 seconds. The more user words, the longer the
>> wait.
> 
> 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. Of course if the words are 
> multiple megabytes long then it might be possible (however the timing you 
> already stated above suggests the loop isn't actually taking 4 seconds!).
> 
>> 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.
> 
> Warmst Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
> ___
> 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
___
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

Re: Speed up a slow loop

[Mark Waddingham via use-livecode]

On 2022-03-02 21:57, J. Landman Gay via use-livecode wrote:

The loop takes forever. Here it is (sDictFile is a script local):

  repeat for each line l in pList -- pList is the user word list
if sDictFile[l] = true then put l & cr after tCheckedList
else put l & cr after tNonWords
wait 0 with messages  -- prevent ANRs
  end repeat

I added the wait because my Android phone was putting up an "app not
responding" warning while the loop was running (or just after, hard to
tell.) The loop should be much faster than that. When I added some
timing checks though, the timer says the loop takes between 0 and 1
millisecond, and yet the wait on screen remains.


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).



With a 3-word user list, the loop takes 4 seconds. With an 8 word user
list the loop takes 6 seconds. The more user words, the longer the
wait.


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. Of course if the words are 
multiple megabytes long then it might be possible (however the timing 
you already stated above suggests the loop isn't actually taking 4 
seconds!).



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.


Warmst Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/2/22 11:41 PM, Richard Gaskin via use-livecode wrote:

Jacque wrote:

 > so I'm not really looping through the keys, just looking for
 > a matching one. The loop is for each user word I need to find.
 > If there's no key, then the word isn't legal.

What is the ratio of keys whose values are "true" and those which are "false"?


There are no false values. The list of words is split as a set, so the keys are the dictionary 
words and all values are true.



And what is the ratio of writes to that array vs reads?


No writes at all, read only. The dictionary is stored gzipped as a custom property. On launch 
it is decompressed, split into an array, and stored in a script local. It's about 1.8 MB 
decompressed, I think. Maybe the array structure adds a bit. Not huge, but not small either. 
The SOWPODS dictionary was twice that size, but my puny tablet had no problem with it.


When the user submits a list of words, the handler sees if the array[userWord] is true. I used 
to just see if the value was empty, but either way it works the same. If no key is available, 
the word is illegal.


BTW, there's another place with a similar slowdown, but one thing at a time. As before, this 
second thing works fine on the tablet but is slow on my phone. Maybe the reason is the same.


--
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/2/22 8:14 PM, Rick Harrison via use-livecode wrote:

That sounds like a memory leak!


I was thinking the same thing, but you'd think it would leak on my old tablet too, the one with 
far less memory.


--
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

Re: Speed up a slow loop

[Richard Gaskin via use-livecode]

Jacque wrote:

> so I'm not really looping through the keys, just looking for
> a matching one. The loop is for each user word I need to find.
> If there's no key, then the word isn't legal.

What is the ratio of keys whose values are "true" and those which are 
"false"?


And what is the ratio of writes to that array vs reads?

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.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

Re: Speed up a slow loop

[Jerry Jensen via use-livecode]

I did not know about filter! I think I am cured of my “among” disease.
.Jerry

> On Mar 2, 2022, at 7:29 PM, Ralph DiMola via use-livecode 
>  wrote:
> 
> I ran into this when doing mobile predictive typing for US cities(40,000)
> with a scrollable dropdown of results. I did with a loop in JavaScript in
> html and was instantly fast. So in LC IDE I started with the loop thing and
> it was too slow. There was a 3/4 of a second blip as each character was
> typed. I found that "filter the lines" is blazingly fast. So I built the cr
> list of cities with the city followed by a dash and then the metadata I
> needed (lat/lons). Use the "filter into" form so the original list remains
> unchanged. I do a filter for each character typed. Works like a charm. Now
> LC is as fast as the JavaScript version. 
> When filtering if you want the exact term then search with the dash added at
> the end for the search term.
> 
> "filter" must be using your time machine somehow.



___
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

RE: Speed up a slow loop

[Ralph DiMola via use-livecode]

I ran into this when doing mobile predictive typing for US cities(40,000)
with a scrollable dropdown of results. I did with a loop in JavaScript in
html and was instantly fast. So in LC IDE I started with the loop thing and
it was too slow. There was a 3/4 of a second blip as each character was
typed. I found that "filter the lines" is blazingly fast. So I built the cr
list of cities with the city followed by a dash and then the metadata I
needed (lat/lons). Use the "filter into" form so the original list remains
unchanged. I do a filter for each character typed. Works like a charm. Now
LC is as fast as the JavaScript version. 
When filtering if you want the exact term then search with the dash added at
the end for the search term.

"filter" must be using your time machine somehow.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of J. Landman Gay via use-livecode
Sent: Wednesday, March 02, 2022 4:58 PM
To: LiveCode Mailing List
Cc: J. Landman Gay
Subject: Speed up a slow loop

In my Boggle game I have an array containing dictionary words as keys, split
as set, so all values are "true". I need to compare those keys with a list
of user words and get back a list of good words and a list of illegal words.

The loop takes forever. Here it is (sDictFile is a script local):

   repeat for each line l in pList -- pList is the user word list
 if sDictFile[l] = true then put l & cr after tCheckedList
 else put l & cr after tNonWords
 wait 0 with messages  -- prevent ANRs
   end repeat

I added the wait because my Android phone was putting up an "app not
responding" warning while the loop was running (or just after, hard to
tell.) The loop should be much faster than that. 
When I added some timing checks though, the timer says the loop takes
between 0 and 1 millisecond, and yet the wait on screen remains.

With a 3-word user list, the loop takes 4 seconds. With an 8 word user list
the loop takes 6 seconds. The more user words, the longer the wait.

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.

I've tried any number of workarounds without luck, on both LC 9.6.6 and LC
10.0.0. Any ideas? I have a feeling it isn't the script per se, it's
something else.

-- 
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


___
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

Re: Speed up a slow loop

[Jerry Jensen via use-livecode]

That does make sense and now I understand the problem. 

> On Mar 2, 2022, at 6:19 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> Actually, this is what I do:
> 
>  if sDictFile[L] = true then...
> 
> which I thought would be pretty fast since it's accessing the array directly. 
> The array looks like this:
> 
> sDictFile
>  word1 -> true
>  word2 -> true
>  word3 -> true
> 
> And my loop does this, for each user word:
> 
>  if sDictFile["word2"] = true then...
> 
> so I'm not really looping through the keys, just looking for a matching one. 
> The loop is for each user word I need to find. If there's no key, then the 
> word isn't legal. I hope that makes sense.
> 
> -- 
> 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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/2/22 6:40 PM, Phil Davis via use-livecode wrote:
Did it ever work as expected, or has it always behaved this way on all devices? (If it ever did 
work right, I guess that points to a change that happened outside your code.)


I'm trying to remember. I've mostly been testing on my tablet where the board has a big enough 
hit region. It's only recently I've tried testing on a phone. I'll go back to some of my 
earlier builds and see how they behave.


Good thought.

--
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/2/22 7:44 PM, Jerry Jensen via use-livecode wrote:

Instead of putting the keys into tCorrWdList and using
“among the lines of tCorrWdList",
how about using “among the keys of tCorrWdList”?

Judging from no knowledge of the internals but guessing what it must do:
“among the lines” has to look for all the line endings (unicode!),
but “among the keys” can jump along by constant offsets since
the keys are all fixed length hashes ?
The lines happen to be all the same length, but “among the lines” can’t assume 
that and has to go look.

Maybe I’m missing something again . . .
.Jerry


Actually, this is what I do:

  if sDictFile[L] = true then...

which I thought would be pretty fast since it's accessing the array directly. The array looks 
like this:


sDictFile
  word1 -> true
  word2 -> true
  word3 -> true

And my loop does this, for each user word:

  if sDictFile["word2"] = true then...

so I'm not really looping through the keys, just looking for a matching one. The loop is for 
each user word I need to find. If there's no key, then the word isn't legal. I hope that makes 
sense.


--
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

Re: Speed up a slow loop

[Rick Harrison via use-livecode]

It could also be the garbage collection cycle isn’t working right.

> On Mar 2, 2022, at 7:52 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> I noticed today though that there's a more general slowdown overall. When I 
> first launch the app it takes only a second to set up the board display. If I 
> keep hitting the "new board" button repeatedly, each setup takes a bit longer.

___
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

Re: Speed up a slow loop

[Rick Harrison via use-livecode]

That sounds like a memory leak!

> On Mar 2, 2022, at 7:52 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> I noticed today though that there's a more general slowdown overall. When I 
> first launch the app it takes only a second to set up the board display. If I 
> keep hitting the "new board" button repeatedly, each setup takes a bit longer.

___
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

Re: Speed up a slow loop

[Rick Harrison via use-livecode]

A few years ago I found that  0.1 milliseconds was faster for some crazy reason.
Maybe that bug finally got fixed?

> On Mar 2, 2022, at 7:40 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> It gets slower. :(

___
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

Re: Speed up a slow loop

[Jerry Jensen via use-livecode]

Arrgh.
Try again.

“among the keys of C” 
instead of the keys of tCorrWdList like I wrote.
I’ll quit now.
.Jerry

> On Mar 2, 2022, at 5:44 PM, Jerry Jensen via use-livecode 
>  wrote:
> 
> Now that I’m thinking more directly, I’ll try again:
> 
> Instead of putting the keys OF C into tCorrWdList and using 
> “among the lines of tCorrWdList",
> how about using “among the keys of tCorrWdList”? — wrong - should have geen 
> the keys of C instead
> 
> Judging from no knowledge of the internals but guessing what it must do: 
> “among the lines” has to look for all the line endings (unicode!), 
> but “among the keys” can jump along by constant offsets since
> the keys are all fixed length hashes ?
> The lines happen to be all the same length, but “among the lines” can’t 
> assume that and has to go look.
> 
> Maybe I’m missing something again . . .
> .Jerry
> 
> 
>> On Mar 2, 2022, at 4:19 PM, Jerry Jensen via use-livecode 
>>  wrote:
>> 
>> Could using “is among the keys of sDictFile” instead of the loop be another 
>> advantage?
>> .Jerry
>> 
>>> On Mar 2, 2022, at 3:12 PM, Devin Asay via use-livecode 
>>>  wrote:
>>> 
>>> Jacque,
>>> 
>>> Have you tried
>>> 
>>> put the keys of C into tCorrWdList
>>> repeat for each line I in pList
>>> if I is among the lines of tCorrWdList then
>>>put I & cr after tCheckedList
>>> else
>>>put I & cr after tNonWords
>>> end if
>>> end repeat
>>> 
>>> I just wonder if there is some overhead with checking the array on each 
>>> iteration.
>>> 
>>> But like you say, it may not be the repeat loop at all.
>>> 
>>> - Devin
>>> 
>>> 
>>> On Mar 2, 2022, at 2:57 PM, J. Landman Gay via use-livecode 
>>> mailto:use-livecode@lists.runrev.com>> wrote:
>>> 
>>> In my Boggle game I have an array containing dictionary words as keys, 
>>> split as set, so all values are "true". I need to compare those keys with a 
>>> list of user words and get back a list of good words and a list of illegal 
>>> words.
>>> 
>>> The loop takes forever. Here it is (sDictFile is a script local):
>>> 
>>> repeat for each line l in pList -- pList is the user word list
>>> if sDictFile[l] = true then put l & cr after tCheckedList
>>> else put l & cr after tNonWords
>>> wait 0 with messages  -- prevent ANRs
>>> end repeat
>>> 
>>> I added the wait because my Android phone was putting up an "app not 
>>> responding" warning while the loop was running (or just after, hard to 
>>> tell.) The loop should be much faster than that. When I added some timing 
>>> checks though, the timer says the loop takes between 0 and 1 millisecond, 
>>> and yet the wait on screen remains.
>>> 
>>> With a 3-word user list, the loop takes 4 seconds. With an 8 word user list 
>>> the loop takes 6 seconds. The more user words, the longer the wait.
>>> 
>>> 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.
>>> 
>>> I've tried any number of workarounds without luck, on both LC 9.6.6 and LC 
>>> 10.0.0. Any ideas? I have a feeling it isn't the script per se, it's 
>>> something else.
>>> 
>>> --
>>> 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
>>> 
>>> Devin Asay
>>> Office of Digital Humanities
>>> Brigham Young University
>>> 
>>> ___
>>> 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
>>> 
>> 
>> 
>> ___
>> 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
> 
> 
> ___
> 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


___
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

Re: Speed up a slow loop

[Jerry Jensen via use-livecode]

Now that I’m thinking more directly, I’ll try again:

Instead of putting the keys into tCorrWdList and using 
“among the lines of tCorrWdList",
how about using “among the keys of tCorrWdList”?

Judging from no knowledge of the internals but guessing what it must do: 
“among the lines” has to look for all the line endings (unicode!), 
but “among the keys” can jump along by constant offsets since
the keys are all fixed length hashes ?
The lines happen to be all the same length, but “among the lines” can’t assume 
that and has to go look.

Maybe I’m missing something again . . .
.Jerry


> On Mar 2, 2022, at 4:19 PM, Jerry Jensen via use-livecode 
>  wrote:
> 
> Could using “is among the keys of sDictFile” instead of the loop be another 
> advantage?
> .Jerry
> 
>> On Mar 2, 2022, at 3:12 PM, Devin Asay via use-livecode 
>>  wrote:
>> 
>> Jacque,
>> 
>> Have you tried
>> 
>> put the keys of C into tCorrWdList
>> repeat for each line I in pList
>>  if I is among the lines of tCorrWdList then
>> put I & cr after tCheckedList
>>  else
>> put I & cr after tNonWords
>>  end if
>> end repeat
>> 
>> I just wonder if there is some overhead with checking the array on each 
>> iteration.
>> 
>> But like you say, it may not be the repeat loop at all.
>> 
>> - Devin
>> 
>> 
>> On Mar 2, 2022, at 2:57 PM, J. Landman Gay via use-livecode 
>> mailto:use-livecode@lists.runrev.com>> wrote:
>> 
>> In my Boggle game I have an array containing dictionary words as keys, split 
>> as set, so all values are "true". I need to compare those keys with a list 
>> of user words and get back a list of good words and a list of illegal words.
>> 
>> The loop takes forever. Here it is (sDictFile is a script local):
>> 
>> repeat for each line l in pList -- pList is the user word list
>>  if sDictFile[l] = true then put l & cr after tCheckedList
>>  else put l & cr after tNonWords
>>  wait 0 with messages  -- prevent ANRs
>> end repeat
>> 
>> I added the wait because my Android phone was putting up an "app not 
>> responding" warning while the loop was running (or just after, hard to 
>> tell.) The loop should be much faster than that. When I added some timing 
>> checks though, the timer says the loop takes between 0 and 1 millisecond, 
>> and yet the wait on screen remains.
>> 
>> With a 3-word user list, the loop takes 4 seconds. With an 8 word user list 
>> the loop takes 6 seconds. The more user words, the longer the wait.
>> 
>> 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.
>> 
>> I've tried any number of workarounds without luck, on both LC 9.6.6 and LC 
>> 10.0.0. Any ideas? I have a feeling it isn't the script per se, it's 
>> something else.
>> 
>> --
>> 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
>> 
>> Devin Asay
>> Office of Digital Humanities
>> Brigham Young University
>> 
>> ___
>> 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
>> 
> 
> 
> ___
> 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


___
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/2/22 6:32 PM, Rick Harrison via use-livecode wrote:

Eon’s ago I had a similar problem in Fortran.

My solution was to break up my huge array into 3 smaller
alphabetical arrays.  I had to first determine with some
if statements which of the 3 arrays I had to search.

The solution turned a glacially slow search into a very acceptable one.

You may want to try a similar solution.


That's a thought, though I hate to go there. I was using the SOWPODS dictionary which has a 
gazillion words, and switched to a different, shorter word list and that did help a bit.


I noticed today though that there's a more general slowdown overall. When I first launch the 
app it takes only a second to set up the board display. If I keep hitting the "new board" 
button repeatedly, each setup takes a bit longer.


--
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

Re: Speed up a slow loop

[Phil Davis via use-livecode]

Jacque -

Did it ever work as expected, or has it always behaved this way on all 
devices? (If it ever did work right, I guess that points to a change 
that happened outside your code.)


Phil Davis


On 3/2/22 4:35 PM, J. Landman Gay via use-livecode wrote:

On 3/2/22 5:12 PM, Devin Asay via use-livecode wrote:

Have you tried

put the keys of sDictFile into tCorrWdList
repeat for each line I in pList
    if I is among the lines of tCorrWdList then
   put I & cr after tCheckedList
    else
   put I & cr after tNonWords
    end if
end repeat


Yeah. No change. But I do appreciate the reply. I've been trying to 
figure this out for 2 days.




--
Phil Davis
503-307-4363


___
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/2/22 5:06 PM, Rick Harrison via use-livecode wrote:

What happens if you wait longer than 0?


It gets slower. :(

--
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/2/22 6:19 PM, Jerry Jensen via use-livecode wrote:

Could using “is among the keys of sDictFile” instead of the loop be another 
advantage?


I need to loop through all the user words, checking each one against the dictionary. I.e. the 
loop is going through a short list of user entries, not the entire dictionary.


Weird, isn't it?

--
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

Re: Speed up a slow loop

[J. Landman Gay via use-livecode]

On 3/2/22 5:12 PM, Devin Asay via use-livecode wrote:

Have you tried

put the keys of sDictFile into tCorrWdList
repeat for each line I in pList
if I is among the lines of tCorrWdList then
   put I & cr after tCheckedList
else
   put I & cr after tNonWords
end if
end repeat


Yeah. No change. But I do appreciate the reply. I've been trying to figure this 
out for 2 days.

--
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

Re: Speed up a slow loop

[Rick Harrison via use-livecode]

Eon’s ago I had a similar problem in Fortran.

My solution was to break up my huge array into 3 smaller
alphabetical arrays.  I had to first determine with some
if statements which of the 3 arrays I had to search.

The solution turned a glacially slow search into a very acceptable one.

You may want to try a similar solution.

Good luck!

Rick

> On Mar 2, 2022, at 4:57 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> In my Boggle game I have an array containing dictionary words as keys, split 
> as set, so all values are "true". I need to compare those keys with a list of 
> user words and get back a list of good words and a list of illegal words.
> 
> The loop takes forever. Here it is (sDictFile is a script local):
> 
>  repeat for each line l in pList -- pList is the user word list
>if sDictFile[l] = true then put l & cr after tCheckedList
>else put l & cr after tNonWords
>wait 0 with messages  -- prevent ANRs
>  end repeat
> 
> I added the wait because my Android phone was putting up an "app not 
> responding" warning while the loop was running (or just after, hard to tell.) 
> The loop should be much faster than that. When I added some timing checks 
> though, the timer says the loop takes between 0 and 1 millisecond, and yet 
> the wait on screen remains.
> 
> With a 3-word user list, the loop takes 4 seconds. With an 8 word user list 
> the loop takes 6 seconds. The more user words, the longer the wait.
> 
> 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.
> 
> I've tried any number of workarounds without luck, on both LC 9.6.6 and LC 
> 10.0.0. Any ideas? I have a feeling it isn't the script per se, it's 
> something else.
> 
> -- 
> 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


___
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

Re: Speed up a slow loop

[Jerry Jensen via use-livecode]

Could using “is among the keys of sDictFile” instead of the loop be another 
advantage?
.Jerry

> On Mar 2, 2022, at 3:12 PM, Devin Asay via use-livecode 
>  wrote:
> 
> Jacque,
> 
> Have you tried
> 
> put the keys of sDictFile into tCorrWdList
> repeat for each line I in pList
>   if I is among the lines of tCorrWdList then
>  put I & cr after tCheckedList
>   else
>  put I & cr after tNonWords
>   end if
> end repeat
> 
> I just wonder if there is some overhead with checking the array on each 
> iteration.
> 
> But like you say, it may not be the repeat loop at all.
> 
> - Devin
> 
> 
> On Mar 2, 2022, at 2:57 PM, J. Landman Gay via use-livecode 
> mailto:use-livecode@lists.runrev.com>> wrote:
> 
> In my Boggle game I have an array containing dictionary words as keys, split 
> as set, so all values are "true". I need to compare those keys with a list of 
> user words and get back a list of good words and a list of illegal words.
> 
> The loop takes forever. Here it is (sDictFile is a script local):
> 
> repeat for each line l in pList -- pList is the user word list
>   if sDictFile[l] = true then put l & cr after tCheckedList
>   else put l & cr after tNonWords
>   wait 0 with messages  -- prevent ANRs
> end repeat
> 
> I added the wait because my Android phone was putting up an "app not 
> responding" warning while the loop was running (or just after, hard to tell.) 
> The loop should be much faster than that. When I added some timing checks 
> though, the timer says the loop takes between 0 and 1 millisecond, and yet 
> the wait on screen remains.
> 
> With a 3-word user list, the loop takes 4 seconds. With an 8 word user list 
> the loop takes 6 seconds. The more user words, the longer the wait.
> 
> 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.
> 
> I've tried any number of workarounds without luck, on both LC 9.6.6 and LC 
> 10.0.0. Any ideas? I have a feeling it isn't the script per se, it's 
> something else.
> 
> --
> 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
> 
> Devin Asay
> Office of Digital Humanities
> Brigham Young University
> 
> ___
> 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
> 


___
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

Re: Speed up a slow loop

[Devin Asay via use-livecode]

Jacque,

Have you tried

put the keys of sDictFile into tCorrWdList
repeat for each line I in pList
   if I is among the lines of tCorrWdList then
  put I & cr after tCheckedList
   else
  put I & cr after tNonWords
   end if
end repeat

I just wonder if there is some overhead with checking the array on each 
iteration.

But like you say, it may not be the repeat loop at all.

- Devin


On Mar 2, 2022, at 2:57 PM, J. Landman Gay via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

In my Boggle game I have an array containing dictionary words as keys, split as 
set, so all values are "true". I need to compare those keys with a list of user 
words and get back a list of good words and a list of illegal words.

The loop takes forever. Here it is (sDictFile is a script local):

 repeat for each line l in pList -- pList is the user word list
   if sDictFile[l] = true then put l & cr after tCheckedList
   else put l & cr after tNonWords
   wait 0 with messages  -- prevent ANRs
 end repeat

I added the wait because my Android phone was putting up an "app not 
responding" warning while the loop was running (or just after, hard to tell.) 
The loop should be much faster than that. When I added some timing checks 
though, the timer says the loop takes between 0 and 1 millisecond, and yet the 
wait on screen remains.

With a 3-word user list, the loop takes 4 seconds. With an 8 word user list the 
loop takes 6 seconds. The more user words, the longer the wait.

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.

I've tried any number of workarounds without luck, on both LC 9.6.6 and LC 
10.0.0. Any ideas? I have a feeling it isn't the script per se, it's something 
else.

--
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

Devin Asay
Office of Digital Humanities
Brigham Young University

___
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

Re: Speed up a slow loop

[Rick Harrison via use-livecode]

What happens if you wait longer than 0?

Rick

> On Mar 2, 2022, at 4:57 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
> In my Boggle game I have an array containing dictionary words as keys, split 
> as set, so all values are "true". I need to compare those keys with a list of 
> user words and get back a list of good words and a list of illegal words.
> 
> The loop takes forever. Here it is (sDictFile is a script local):
> 
>  repeat for each line l in pList -- pList is the user word list
>if sDictFile[l] = true then put l & cr after tCheckedList
>else put l & cr after tNonWords
>wait 0 with messages  -- prevent ANRs
>  end repeat
> 
> I added the wait because my Android phone was putting up an "app not 
> responding" warning while the loop was running (or just after, hard to tell.) 
> The loop should be much faster than that. When I added some timing checks 
> though, the timer says the loop takes between 0 and 1 millisecond, and yet 
> the wait on screen remains.
> 
> With a 3-word user list, the loop takes 4 seconds. With an 8 word user list 
> the loop takes 6 seconds. The more user words, the longer the wait.
> 
> 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.
> 
> I've tried any number of workarounds without luck, on both LC 9.6.6 and LC 
> 10.0.0. Any ideas? I have a feeling it isn't the script per se, it's 
> something else.
> 
> -- 
> 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


___
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

Speed up a slow loop

[J. Landman Gay via use-livecode]

In my Boggle game I have an array containing dictionary words as keys, split as set, so all 
values are "true". I need to compare those keys with a list of user words and get back a list 
of good words and a list of illegal words.


The loop takes forever. Here it is (sDictFile is a script local):

  repeat for each line l in pList -- pList is the user word list
if sDictFile[l] = true then put l & cr after tCheckedList
else put l & cr after tNonWords
wait 0 with messages  -- prevent ANRs
  end repeat

I added the wait because my Android phone was putting up an "app not responding" warning while 
the loop was running (or just after, hard to tell.) The loop should be much faster than that. 
When I added some timing checks though, the timer says the loop takes between 0 and 1 
millisecond, and yet the wait on screen remains.


With a 3-word user list, the loop takes 4 seconds. With an 8 word user list the loop takes 6 
seconds. The more user words, the longer the wait.


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.


I've tried any number of workarounds without luck, on both LC 9.6.6 and LC 10.0.0. Any ideas? I 
have a feeling it isn't the script per se, it's something else.


--
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

Re: LC 9.6.5 RC 2 Speed Test

[Curry Kenworthy via use-livecode]

Mark:

 > Is there any chance you can package up the files used to test
 > along with the stack and submit as an issue to BZ?
 > That way we can take a look to see what is causing
 > the significant differences with C and E, in particular?

Here it is!

I just posted the set of test files
(and results again with file names included)
plus the test stack download link
to the existing speed bug here:

https://quality.livecode.com/show_bug.cgi?id=21561

Thanks again

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
Christian LiveCode Training and Consulting
http://livecodeconsulting.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

Re: LC 9.6.5 RC 2 Speed Test

[Mark Waddingham via use-livecode]

On 2021-11-05 12:32, Curry Kenworthy via use-livecode wrote:

Absolutely; thanks!
I'll do that within the next few days.

(Should I use the old speed bug 21561 or a new one?)


If you just add it as another example stack to Bug 21561 that would be 
fine - there's a good chance its multiple actual issues (just as the 
existing stack is/was) :)


Thanks in advance!

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: LC 9.6.5 RC 2 Speed Test

[Curry Kenworthy via use-livecode]

Mark:

> Is there any chance you can package up the files used to test
> along with the stack and submit as an issue to BZ?
> That way we can take a look to see what is causing
> the significant differences with C and E, in particular?

Absolutely; thanks!
I'll do that within the next few days.

(Should I use the old speed bug 21561 or a new one?)

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
Christian LiveCode Training and Consulting
http://livecodeconsulting.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

Re: LC 9.6.5 RC 2 Speed Test

[Mark Waddingham via use-livecode]

On 2021-11-05 11:05, Curry Kenworthy via use-livecode wrote:

My first LC 9.6.5 RC 2 Speed Test -

Results on Windows 10, current WordLib

Ratings:

- LC 9.6.5 RC 2 vs LC 9.6.3: 5 Wins, 0 Losses
- LC 9.6.5 RC 2 vs LC 6.7.11: 2 Wins, 3 Losses

Conclusion:

Good progress; if we follow up on these gains
and locate other areas needing optimization,
LC 10/11 can be pretty fleet of foot!


Well that is pleasing to see.

Is there any chance you can package up the files used to test along with 
the stack and submit as an issue to BZ? That way we can take a look to 
see what is causing the significant differences with C and E, in 
particular?


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

LC 9.6.5 RC 2 Speed Test

[Curry Kenworthy via use-livecode]

My first LC 9.6.5 RC 2 Speed Test -

Results on Windows 10, current WordLib

- LC 9.6.3:

A.docx - 0.073 seconds
B.docx - 0.518 seconds
C.docx - 0.321 seconds
D.docx - 0.314 seconds
E.docx - 9.202 seconds

- LC 9.6.5 RC 2:

A.docx - 0.05 seconds
B.docx - 0.484 seconds
C.docx - 0.284 seconds
D.docx - 0.289 seconds
E.docx - 7.196 seconds

LC 6.7.11:

A.docx - 0.057 seconds
B.docx - 0.362 seconds
C.docx - 0.114 seconds
D.docx - 0.338 seconds
E.docx - 2.991 seconds

Ratings:

- LC 9.6.5 RC 2 vs LC 9.6.3: 5 Wins, 0 Losses
- LC 9.6.5 RC 2 vs LC 6.7.11: 2 Wins, 3 Losses

Conclusion:

Good progress; if we follow up on these gains
and locate other areas needing optimization,
LC 10/11 can be pretty fleet of foot!

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
Christian LiveCode Training and Consulting
http://livecodeconsulting.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

Re: Animation Engine: speed tips

[David Bovill via use-livecode]

Here is a short video of a really nice ball animation of the Earth’s Carbon 
Cycle - which is the sort of thing I’d like to make a series of animations / 
interactive simulations about. There a re a few more than 30-40 moving balls 
here - but they are more or less dots….

https://www.youtube.com/watch?v=dwVsD9CiokY

I wonder how many particles can be animated like this in Livecode...
On 2 Jul 2020, 20:53 +0100, David Bovill , wrote:
> That's inspired me :)
>
> I think it may be possible to do what I want in Livecode - which would be 
> great. Thanks Alex and Bernd :)
>
> > On Thu, 2 Jul 2020 at 20:36, Alex Tweedly via use-livecode 
> >  wrote:
> > >
> > > On 01/07/2020 02:52, J. Landman Gay via use-livecode wrote:
> > > > Did you use acceleratedRendering? Set it to true and set the layermode
> > > > of each moving object to dynamic. I'd be curious to see if there's a
> > > > difference.
> > > >
> > > >
> > > Hadn't  tried those until now. There is a difference - but not the kind
> > > I'd hoped for :-)
> > >
> > > Full script is below with detailed time, but the summary is:
> > > - acceleratedRendering made things much worse (50% to 90% slower)
> > > - dynamic layerMode made things a little bit better (5% to 15%).
> > >
> > > If the circle was moving over a plain background, improvement was only
> > > 5%-ish, while if moving over multiple other shapes, it gave a better
> > > improvement.
> > >
> > > Here's the full snippet of the script involved (other cases obvious :-)
> > >
> > > >   set the acceleratedRendering of this stack to false
> > > >    set the layermode of grc "g1" to "static"
> > > >
> > > >    repeat 3 times
> > > >   put 100,400 into tmp
> > > >   put the millisecs into tim1
> > > >   repeat 100 times
> > > >  add 1 to item 1 of tmp
> > > >  set the loc of grc "g1" to tmp
> > > >  wait 0 with messages
> > > >   end repeat
> > > >   put the acceleratedRendering of this stack && \
> > > >     the layermode of grc "g1" \
> > > >     && the millisecs-tim1 &CR after gLog
> > > >    end repeat
> > > >    put CR after gLog
> > >
> > > Here are the times for each of the cases, moving 100 times
> > >
> > > false static 192
> > > false static 154
> > > false static 155
> > >
> > > true static 285
> > > true static 332
> > > true static 249
> > >
> > > true dynamic 265
> > > true dynamic 255
> > > true dynamic 309
> > >
> > > false dynamic 131
> > > false dynamic 134
> > > false dynamic 149
> > >
> > > Alex.
> > >
> > >
> > > ___
> > > 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
___
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

Re: Animation Engine: speed tips

[David Bovill via use-livecode]

That's inspired me :)

I think it may be possible to do what I want in Livecode - which would be
great. Thanks Alex and Bernd :)

On Thu, 2 Jul 2020 at 20:36, Alex Tweedly via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> On 01/07/2020 02:52, J. Landman Gay via use-livecode wrote:
> > Did you use acceleratedRendering? Set it to true and set the layermode
> > of each moving object to dynamic. I'd be curious to see if there's a
> > difference.
> >
> >
> Hadn't  tried those until now. There is a difference - but not the kind
> I'd hoped for :-)
>
> Full script is below with detailed time, but the summary is:
> - acceleratedRendering made things much worse (50% to 90% slower)
> - dynamic layerMode made things a little bit better (5% to 15%).
>
> If the circle was moving over a plain background, improvement was only
> 5%-ish, while if moving over multiple other shapes, it gave a better
> improvement.
>
> Here's the full snippet of the script involved (other cases obvious :-)
>
> >   set the acceleratedRendering of this stack to false
> >set the layermode of grc "g1" to "static"
> >
> >repeat 3 times
> >   put 100,400 into tmp
> >   put the millisecs into tim1
> >   repeat 100 times
> >  add 1 to item 1 of tmp
> >  set the loc of grc "g1" to tmp
> >  wait 0 with messages
> >   end repeat
> >   put the acceleratedRendering of this stack && \
> > the layermode of grc "g1" \
> > && the millisecs-tim1 &CR after gLog
> >end repeat
> >put CR after gLog
>
> Here are the times for each of the cases, moving 100 times
>
> false static 192
> false static 154
> false static 155
>
> true static 285
> true static 332
> true static 249
>
> true dynamic 265
> true dynamic 255
> true dynamic 309
>
> false dynamic 131
> false dynamic 134
> false dynamic 149
>
> Alex.
>
>
> ___
> 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
>
___
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

Re: Animation Engine: speed tips

[Alex Tweedly via use-livecode]

On 01/07/2020 02:52, J. Landman Gay via use-livecode wrote:
Did you use acceleratedRendering? Set it to true and set the layermode 
of each moving object to dynamic. I'd be curious to see if there's a 
difference.



Hadn't  tried those until now. There is a difference - but not the kind 
I'd hoped for :-)


Full script is below with detailed time, but the summary is:
- acceleratedRendering made things much worse (50% to 90% slower)
- dynamic layerMode made things a little bit better (5% to 15%).

If the circle was moving over a plain background, improvement was only 
5%-ish, while if moving over multiple other shapes, it gave a better 
improvement.


Here's the full snippet of the script involved (other cases obvious :-)


  set the acceleratedRendering of this stack to false
   set the layermode of grc "g1" to "static"

   repeat 3 times
  put 100,400 into tmp
  put the millisecs into tim1
  repeat 100 times
 add 1 to item 1 of tmp
 set the loc of grc "g1" to tmp
 wait 0 with messages
  end repeat
  put the acceleratedRendering of this stack && \
    the layermode of grc "g1" \
    && the millisecs-tim1 &CR after gLog
   end repeat
   put CR after gLog


Here are the times for each of the cases, moving 100 times

false static 192
false static 154
false static 155

true static 285
true static 332
true static 249

true dynamic 265
true dynamic 255
true dynamic 309

false dynamic 131
false dynamic 134
false dynamic 149

Alex.


___
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

Re: Animation Engine: speed tips

[Niggemann, Bernd via use-livecode]

Thank you Mark,

Glad you enjoyed it.

If you feel like it you could set the markerPoints of graphic gSand to a ball, 
still running at 22 frames/sec with 500 of them, filled. 

--
0,-13
3,-13
6,-12
8,-11
10,-9
12,-6
13,-3
13,0
13,3
12,6
10,9
8,11
6,12
3,13
0,13
-3,13
-6,12
-8,11
-10,9
-12,6
-13,3
-13,0
-13,-3
-12,-6
-10,-9
-8,-11
-6,-12
-3,-13
0,-13
-

Kind regards
Bernd

> Mark Talluto via use-livecode Wed, 01 Jul 2020 20:55:00 -0700
> 
> This is completely awesome!  Thank you Bernd.
> 
> -Mark Talluto
> Canela Software
> 
> On Wed, Jul 1, 2020 at 8:27 AM Niggemann, Bernd via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
> > While not exactly what David asked for but on the topic  of animating
> > multiple objects with acceptable speed:
> >
> > http://forums.livecode.com/viewtopic.php?f=10&t=11726&hilit=sand#p56253



___
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

Re: Animation Engine: speed tips

[Mark Talluto via use-livecode]

This is completely awesome!  Thank you Bernd.

-Mark Talluto
Canela Software

On Wed, Jul 1, 2020 at 8:27 AM Niggemann, Bernd via use-livecode <
use-livecode@lists.runrev.com> wrote:

> While not exactly what David asked for but on the topic  of animating
> multiple objects with acceptable speed:
>
> http://forums.livecode.com/viewtopic.php?f=10&t=11726&hilit=sand#p56253
>
> The original poster asked for "sand" particles that should have some sort
> of collision detection and should react to a mouseDown to either attract
> the objects or pushes them away.
>
> It uses _one_ polygon graphic and sets individual points of that graphic
> (separated by an empty line). The points are just x,y coordinates and
> markers make the visual objects of the moving parts.
>
> It manages to animate quite some number of objects depending on the size
> of the markers and some other features that are optional (dropshadow,
> ounteglow, markers filled and antialiasing)
>
> The stack is completely useless but perfect for a rainy day at home.
> Depending on the complexity of the marker graphic it manages to animate
> smoothly (frame rate 18 and up)  from 150 to 1500 (small) objects (you can
> change appearance while the objects are moving.
>
> Kind regards
> Bernd
> ___
> 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
>
___
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

Re: Animation Engine: speed tips

[Niggemann, Bernd via use-livecode]

While not exactly what David asked for but on the topic  of animating multiple 
objects with acceptable speed:

http://forums.livecode.com/viewtopic.php?f=10&t=11726&hilit=sand#p56253

The original poster asked for "sand" particles that should have some sort of 
collision detection and should react to a mouseDown to either attract the 
objects or pushes them away.

It uses _one_ polygon graphic and sets individual points of that graphic 
(separated by an empty line). The points are just x,y coordinates and markers 
make the visual objects of the moving parts.

It manages to animate quite some number of objects depending on the size of the 
markers and some other features that are optional (dropshadow, ounteglow, 
markers filled and antialiasing)

The stack is completely useless but perfect for a rainy day at home. 
Depending on the complexity of the marker graphic it manages to animate 
smoothly (frame rate 18 and up)  from 150 to 1500 (small) objects (you can 
change appearance while the objects are moving.

Kind regards
Bernd
___
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

Re: Animation Engine: speed tips

[scott--- via use-livecode]

en (out of window) the time taken drops to 
> 0.
> 
> 2. If you remove the "add 1 to item 1 of tmp" (i.e. the graphic remains in 
> the same place), then again the time drops to effectively 0.
> 
> So with this simple code, I find that (on my aging Macbook Pro), those 100 
> moves take between 125 and 275 ms (i.e. just about 1 to 2.5 ms per shape to 
> move). And that variation is easily matched against the complexity of the 
> surroundings the piece is moving through - if it moves over (or under) many 
> other graphic objects, it takes clearly longer.
> 
> Good luck.
> 
> On 28/06/2020 01:09, David Bovill via use-livecode wrote:
> 
>> I made a quick test - creating and animating small graphic circles along a 
>> complex curve with many points. It works fine with one or two animated 
>> spheres but I’d like to be able to animate >30 and it slows to a crawl after 
>> 4 or 5. I tried setting the layer mode appropriately for all the objects - 
>> but I’m doing this on a new MacBook Pro - and it does not make a difference.
>> 
>> Does anyone have an example stack with multiple animated objects that I can 
>> compare / test for speed?
>> ___
>> 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

___
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

Re: Animation Engine: speed tips

[J. Landman Gay via use-livecode]

On 28/06/2020 01:09, David Bovill via use-livecode wrote:

I made a quick test - creating and animating small graphic circles along a 
complex curve with many points. It works fine with one or two animated 
spheres but I’d like to be able to animate >30 and it slows to a crawl 
after 4 or 5. I tried setting the layer mode appropriately for all the 
objects - but I’m doing this on a new MacBook Pro - and it does not make a 
difference.


Does anyone have an example stack with multiple animated objects that I can 
compare / test for speed?

___
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


___
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





___
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

Re: Animation Engine: speed tips

[Alex Tweedly via use-livecode]

o a crawl after 4 or 5. I tried 
setting the layer mode appropriately for all the objects - but I’m doing this on a 
new MacBook Pro - and it does not make a difference.

Does anyone have an example stack with multiple animated objects that I can 
compare / test for speed?
___
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


___
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

Re: OFFLIST Re: Animation Engine: speed tips

[Martin Koob via use-livecode]

The first rule of OFFLIST is you don’t cc to the list.  :-)

But, I too an interested in what Malte is up to.  
Hope all things are going well for you Malte.

Martin


> On Jun 29, 2020, at 1:14 PM, Richard Gaskin via use-livecode 
>  wrote:
> 
> D'oh! My bad, I'd meant to not take up list space with this.
> 
> But we all love Malte, and maybe he won't mind taking a moment to let us know 
> what he's working on lately.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> 
> 
> Colin wrote:
>> We’re all curious!
>>> On Jun 29, 2020, at 9:26 AM, Richard Gaskin via use-livecode >> at lists.runrev.com> wrote:
>>> On the use-livecode list you wrote:
>>> > Hey Alex,
>>> >
>>> > Public Domain it is. I’ve set it free couple. of years back, as I am
>>> > essentially no longer writing code. :-) Still following LiveCodes
>>> > progress with interest though.  :-)
>>> >
>>> > Cheers,
>>> >
>>> > Malte
>>> If you're no coding, what are you up to these days?
> 
> 
> ___
> 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


___
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

Re: OFFLIST Re: Animation Engine: speed tips

[Richard Gaskin via use-livecode]

D'oh! My bad, I'd meant to not take up list space with this.

But we all love Malte, and maybe he won't mind taking a moment to let us 
know what he's working on lately.


--
 Richard Gaskin
 Fourth World Systems


Colin wrote:

We’re all curious!


On Jun 29, 2020, at 9:26 AM, Richard Gaskin via use-livecode  wrote:

On the use-livecode list you wrote:
> Hey Alex,
>
> Public Domain it is. I’ve set it free couple. of years back, as I am
> essentially no longer writing code. :-) Still following LiveCodes
> progress with interest though.  :-)
>
> Cheers,
>
> Malte

If you're no coding, what are you up to these days?



___
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

Re: OFFLIST Re: Animation Engine: speed tips

[Colin Holgate via use-livecode]

We’re all curious!

> On Jun 29, 2020, at 9:26 AM, Richard Gaskin via use-livecode 
>  wrote:
> 
> On the use-livecode list you wrote:
> > Hey Alex,
> >
> > Public Domain it is. I’ve set it free couple. of years back, as I am
> > essentially no longer writing code. :-) Still following LiveCodes
> > progress with interest though.  :-)
> >
> > Cheers,
> >
> > Malte
> 
> If you're no coding, what are you up to these days?
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.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


___
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

OFFLIST Re: Animation Engine: speed tips

[Richard Gaskin via use-livecode]

On the use-livecode list you wrote:
> Hey Alex,
>
> Public Domain it is. I’ve set it free couple. of years back, as I am
> essentially no longer writing code. :-) Still following LiveCodes
> progress with interest though.  :-)
>
> Cheers,
>
> Malte

If you're no coding, what are you up to these days?

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.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

Re: Animation Engine: speed tips

[Alex Tweedly via use-livecode]

Thanks Malte. Hope you are enjoying whatever it is you're doing instead 
of writing code :-)


Thanks again for having put AE into the Public Domain.

Alex.

On 29/06/2020 10:15, Malte Pfaff-Brill via use-livecode wrote:

Hey Alex,

Public Domain it is. I’ve set it free couple. of years back, as I am 
essentially no longer writing code. :-) Still following LiveCodes progress with 
interest though.  :-)

Cheers,

Malte
___
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


___
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

Re: Animation Engine: speed tips

[Malte Pfaff-Brill via use-livecode]

Hey Alex,

Public Domain it is. I’ve set it free couple. of years back, as I am 
essentially no longer writing code. :-) Still following LiveCodes progress with 
interest though.  :-)

Cheers,

Malte
___
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

Re: Animation Engine: speed tips

[Alex Tweedly via use-livecode]

Hi there submariner :-),

can you just confirm the licensing of AE ?

The demo code says it is dual Commercial & GLPL3 - but GitHub says it is 
Public Domain.


Can you just say which of those is correct ?

Thanks

Alex.

On 28/06/2020 10:27, Malte Pfaff-Brill via use-livecode wrote:

Hi,

off
it. might be worth digging into AEs source and change the handlers from using 
cProps to local variables.  Also,  there might be unnecessary instances. of 
locking / unlocking screen that. should be refactored in AE.
If anyone is going to take that up I’d be happy iff you shared your patches to 
the community. :-)
on

All the. Best,

Malte
___
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


___
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

Re: Animation Engine: speed tips

[David Bovill via use-livecode]

OK - will take a look. I suspect it is due to too many messages being sent due 
to the sort of line that is drawn when you create a curve by hand….
On 28 Jun 2020, 10:28 +0100, Malte Pfaff-Brill via use-livecode 
, wrote:
> Hi,
>
> off
> it. might be worth digging into AEs source and change the handlers from using 
> cProps to local variables. Also, there might be unnecessary instances. of 
> locking / unlocking screen that. should be refactored in AE.
> If anyone is going to take that up I’d be happy iff you shared your patches 
> to the community. :-)
> on
>
> All the. Best,
>
> Malte
> ___
> 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
___
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