Re: publish and surprise

[Mark Wieder via use-livecode]

On 10/2/19 6:59 AM, Paul Dupuis via use-livecode wrote:
I would love to see a publish and subscribe system in the engine for use 
in Standalone.


I made a PubSub dispatcher library some years ago. If the livecodeshare 
or whatever it's called now website is back in operation it should be 
there. But not having to use Yet Another Library within the IDE is 
awesome. In the past this has only been useful to a proscribed set of 
messages and stacks which has been limiting. My PowerTools plugin, for 
instance, has some unused controls that are necessary because other 
places in the IDE send mouseUp messages to controls that are expected to 
exist in particular places. Decoupling those messages through publishing 
and subscribing removes the dependency and the need for in-depth 
knowledge of the internal workings of other stacks. And leads the way 
for the IDE to be a framework for a collection of independent stacks.


Ah... found it.
http://livecodeshare.runrev.com/stack/714/Publish-and-Subscribe

That took some doing. Any idea why livecodeshare is at runrev.com 
instead of livecode.com/org whatever? I would have thought there would 
at least be a redirect, but livecodeshare.livecode.com just throws a 404.


--
 Mark Wieder
 ahsoftw...@gmail.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: publish and surprise

[Paul Dupuis via use-livecode]

I would love to see a publish and subscribe system in the engine for use 
in Standalone.


I've written a LCS library for for publish and subscribe within our 
commercial apps, but would toss it in an instant for a good engine 
implementation.


Beyond abstracted commands like:
revIDESubscribe "helloworld" -> subscribe 
ideMessageSendWithParameters "helloworld" -> publish  with 
, which could just be existing "send" or "dispatch"


You need a general suppress messages/unsuppress messages, which we have 
as "lock messages" and "unlock messages" already in the language.


You also need an "unsubscribe " and a "lock  
messages [for ]" / "unlock  messages [for 
]" to allow suppression/unsuppression of a specific message for 
all objects or for specific object.


We already have "the pendingMessages" and "cancel", but you would also 
want to add "the subscribers [of ]" for a list of long IDs 
of objects and their messages or filtered for a specific message 
subscribed to and "the publishers [of ]" for a similar list 
of object IDs when the messages they publish or filtered for a specific 
message.


Or perhaps I have been thinking too much about this!


On 10/2/2019 8:58 AM, Tom Glod via use-livecode wrote:

thats what i'm thiking about..its only documented in the "create a plugin"
sections.  But having this in standalones would be a bit of news.

So every message the engine sends is checked to see if there is a
subscription to that message and then all objects ( whether in the path or
not. ) that are subscribed would receive a message that this message was
triggered. That is pretty cool!

On Wed, Oct 2, 2019 at 8:53 AM Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:


On 10/1/2019 11:52 PM, Mark Wieder via use-livecode wrote:

I have finally gotten around to noticing that LC9.x builds have opened
the publish-and-subscribe mechanism to arbitrary messages. I'm not
sure when this happened and I'm really not inclined to go searching
through all those release notes, but I'm ecstatic over the surprise
discovery. This means objects can register interest in certain
messages to do something like

object1:
revIDESubscribe "helloworld"

object2:
revIDESubscribe "helloworld"

object3:
ideMessageSendWithParameters "helloworld"

and both object1 and object2 will get notifications, fully
implementing the Publish-and-Subscribe design pattern.

Thank you team.


Have you tested this is a standalone?

I thought (probably incorrectly) that revIDE... functions/commands were
only available when running in the IDE?


___
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: publish and surprise

[Tom Glod via use-livecode]

thats what i'm thiking about..its only documented in the "create a plugin"
sections.  But having this in standalones would be a bit of news.

So every message the engine sends is checked to see if there is a
subscription to that message and then all objects ( whether in the path or
not. ) that are subscribed would receive a message that this message was
triggered. That is pretty cool!

On Wed, Oct 2, 2019 at 8:53 AM Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 10/1/2019 11:52 PM, Mark Wieder via use-livecode wrote:
> > I have finally gotten around to noticing that LC9.x builds have opened
> > the publish-and-subscribe mechanism to arbitrary messages. I'm not
> > sure when this happened and I'm really not inclined to go searching
> > through all those release notes, but I'm ecstatic over the surprise
> > discovery. This means objects can register interest in certain
> > messages to do something like
> >
> > object1:
> > revIDESubscribe "helloworld"
> >
> > object2:
> > revIDESubscribe "helloworld"
> >
> > object3:
> > ideMessageSendWithParameters "helloworld"
> >
> > and both object1 and object2 will get notifications, fully
> > implementing the Publish-and-Subscribe design pattern.
> >
> > Thank you team.
> >
>
> Have you tested this is a standalone?
>
> I thought (probably incorrectly) that revIDE... functions/commands were
> only available when running in the IDE?
>
>
> ___
> 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
>


-- 
Tom Glod
Founder & Developer
MakeShyft R.D.A (www.makeshyft.com)
Office:226-706-9339
Mobile:226-706-9793
___
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: publish and surprise

[Paul Dupuis via use-livecode]

On 10/1/2019 11:52 PM, Mark Wieder via use-livecode wrote:
I have finally gotten around to noticing that LC9.x builds have opened 
the publish-and-subscribe mechanism to arbitrary messages. I'm not 
sure when this happened and I'm really not inclined to go searching 
through all those release notes, but I'm ecstatic over the surprise 
discovery. This means objects can register interest in certain 
messages to do something like


object1:
revIDESubscribe "helloworld"

object2:
revIDESubscribe "helloworld"

object3:
ideMessageSendWithParameters "helloworld"

and both object1 and object2 will get notifications, fully 
implementing the Publish-and-Subscribe design pattern.


Thank you team.



Have you tested this is a standalone?

I thought (probably incorrectly) that revIDE... functions/commands were 
only available when running in the IDE?



___
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

publish and surprise

[Mark Wieder via use-livecode]

I have finally gotten around to noticing that LC9.x builds have opened 
the publish-and-subscribe mechanism to arbitrary messages. I'm not sure 
when this happened and I'm really not inclined to go searching through 
all those release notes, but I'm ecstatic over the surprise discovery. 
This means objects can register interest in certain messages to do 
something like


object1:
revIDESubscribe "helloworld"

object2:
revIDESubscribe "helloworld"

object3:
ideMessageSendWithParameters "helloworld"

and both object1 and object2 will get notifications, fully implementing 
the Publish-and-Subscribe design pattern.


Thank you team.

--
 Mark Wieder
 ahsoftw...@gmail.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: Surprise...

[Curry Kenworthy via use-livecode]

Mark T:

> In my particular use of arrays and lists, I find the
> lists to be a little more than 2 times faster

Thanks! (Noting: particular use, and methods used.) Optimizing LCS is 
extremely important, and methods that are great for testing items and 
arrays themselves may not be the fastest methods for real applications. 
I'm always glad to help people achieve better results, so let me know if 
you ever need a hand for your purpose.


But ( again :) ) my greater interest in this thread was, and remains, 
seeing the LC engine further optimized! That would really pay off.


Richard:

> Does anyone here have benchmarks comparing LC to Python,
> JavaScript, Lua, and/or other popular scripting languages?

No, but it's a very good pursuit. I would expect some interesting 
results with JS. I won't have time to test these myself for a while but 
I'll remain interested.


Best wishes,

Curry Kenworthy

Custom Software Development
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: Surprise...

[Mark Talluto via use-livecode]

Hi Curry,

The stack can be found here: 
http://canelasoftware.com/pub/livecode/GetColumnCode.zip 

In my particular use of arrays and lists, I find the lists to be a little more 
than 2 times faster than arrays. This test is operating off an array with 100k 
records.

Best regards,

Mark Talluto
livecloud.io 
nursenotes.net 
canelasoftware.com 


> On Aug 20, 2018, at 2:03 PM, Curry Kenworthy via use-livecode 
>  wrote:
> 
> Mark T.:
> 
> > I wrote a stack that demonstrated this and other concepts for
> > LC Mark directly. His Global talks called ‘Optimizing Your Code’
> > are partially based on some things we have been discussing.

___
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: Surprise...

[jbv via use-livecode]

Brian,

Thanks for running all these tests.

On the same topic, I'd like to mention that I use "intersect" with
arrays a lot in some scripts (for complex requests it is sometimes
faster to load raw data from mySQL and process it with arrays),
and "intersect" is really fast in LC9...

On Tue, August 21, 2018 4:24 pm, Brian Milby via use-livecode wrote:
> I expanded my test stack and ran it on the versions I had available.
> Here's a couple of tests from each version:
>




___
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: Surprise...

[Richard Gaskin via use-livecode]

Curry Kenworthy wrote:

> In case I was unclear, I just meant that the engine still can and
> should be optimized! As time and budget allows of course, but
> certainly doable.

You know I'm fairly obsessive about performance.

Does anyone here have benchmarks comparing LC to Python, JavaScript, 
Lua, and/or other popular scripting languages?


--
 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: Surprise...

[Brian Milby via use-livecode]

The one optimization that would really help in this particular torture test
would be native lists.  Then you go from a hash lookup to an index lookup.
I know it will be faster than array, but not sure where it would switch
over and be faster than item.

On Tue, Aug 21, 2018 at 5:33 PM, Curry Kenworthy via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> In case I was unclear, I just meant that the engine still can and should
> be optimized! As time and budget allows of course, but certainly doable. I
> doubt it's only the Unicode and nothing else, but either way it doesn't
> rule out future speed gains. Unicode shouldn't need to slow down everything
> from math to non-text loops (and I remember working on some tests to keep
> the text out of these, but haven't tried that with 9 yet) nor would it
> remove all opportunities for innovation and simplification that lead to
> faster execution.
>
> Most code can be improved, that's a safe bet with few exceptions, and
> speed is an improvement that would do LC a lot of good. Not just tiny
> gains; I do think it's possible and desirable for a Unicode LC engine to
> beat LC 6 in most areas. If I'm alone in that desire, well, color me
> surprised! That's my nature. I may be slow at times but I like my code
> fast. I love optimization and there are some pretty interesting methods to
> achieve it. Very optimized scripts on a very optimized engine is a scenario
> very much to my liking. Wouldn't be a bad selling point either. I'll shut
> up now and dive back in my coding hole where I belong. Addon updates and
> client updates in the works. :)
>
> Best wishes,
>
> Curry Kenworthy
>
> Custom Software Development
> 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
>
___
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: Surprise...

[Curry Kenworthy via use-livecode]

In case I was unclear, I just meant that the engine still can and should 
be optimized! As time and budget allows of course, but certainly doable. 
I doubt it's only the Unicode and nothing else, but either way it 
doesn't rule out future speed gains. Unicode shouldn't need to slow down 
everything from math to non-text loops (and I remember working on some 
tests to keep the text out of these, but haven't tried that with 9 yet) 
nor would it remove all opportunities for innovation and simplification 
that lead to faster execution.


Most code can be improved, that's a safe bet with few exceptions, and 
speed is an improvement that would do LC a lot of good. Not just tiny 
gains; I do think it's possible and desirable for a Unicode LC engine to 
beat LC 6 in most areas. If I'm alone in that desire, well, color me 
surprised! That's my nature. I may be slow at times but I like my code 
fast. I love optimization and there are some pretty interesting methods 
to achieve it. Very optimized scripts on a very optimized engine is a 
scenario very much to my liking. Wouldn't be a bad selling point either. 
I'll shut up now and dive back in my coding hole where I belong. Addon 
updates and client updates in the works. :)


Best wishes,

Curry Kenworthy

Custom Software Development
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: Surprise...

[Brian Milby via use-livecode]

I am pretty sure it was the unicode.  Notice that 7 took a major hit, but
then dramatically improved in 8 and had another step in 9 (for the item).
Doesn't look like the array portion changed much after the rewrite (did
take a slight step back from 7 to 8, but improved with 9).

On Tue, Aug 21, 2018 at 3:38 PM, Tom Glod via use-livecode <
use-livecode@lists.runrev.com> wrote:

> maybe when the new chunk types were added  it put some overhead on
> operations on other chunks? weird
>
> On Tue, Aug 21, 2018 at 4:27 PM, Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > Wasn't it Unicode that slowed everything, especially string parsing down?
> >
> > Bob S
> >
> >
> > > On Aug 21, 2018, at 11:00 , Curry Kenworthy via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> > >
> > > Brian:
> > >
> > > > I expanded my test stack and ran it
> > > > on the versions I had available.
> > >
> > > Thanks for (among other things!) running these tests.
> > >
> > > It's useful to see the item vs array turning point.
> > >
> > > I also notice something else, if I read your result correctly: LC9
> beats
> > LC8 on these tests (that's a good sign!) but LC6 still dominates them
> all,
> > in this particular type of exercise that you've coded, on Mac. It was
> also
> > the winner in my previous tests on Windows.
> > >
> > > ("The Un...defeated... Defen...ding... Champion!")
> > >
> > > I hope to see LC9/10 further optimized. I love LC6, but you must
> > understand I'm always entirely rooting for the latest version and hoping
> > for it to wipe the floor with the others. When it wins, we all win.
> > >
> > > Plenty of methods and tricks to optimize LCS code, and the results may
> > vary between releases and platforms, but engine optimization really is
> > helpful. Its performance establishes the boundaries that we work within
> > while scripting. When I get some time I'll run a new round of tests too
> and
> > publish the results. Thanks again.
> > >
> > > Best wishes,
> > >
> > > Curry K.
> >
> >
> > ___
> > 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: Surprise...

[Tom Glod via use-livecode]

maybe when the new chunk types were added  it put some overhead on
operations on other chunks? weird

On Tue, Aug 21, 2018 at 4:27 PM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Wasn't it Unicode that slowed everything, especially string parsing down?
>
> Bob S
>
>
> > On Aug 21, 2018, at 11:00 , Curry Kenworthy via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Brian:
> >
> > > I expanded my test stack and ran it
> > > on the versions I had available.
> >
> > Thanks for (among other things!) running these tests.
> >
> > It's useful to see the item vs array turning point.
> >
> > I also notice something else, if I read your result correctly: LC9 beats
> LC8 on these tests (that's a good sign!) but LC6 still dominates them all,
> in this particular type of exercise that you've coded, on Mac. It was also
> the winner in my previous tests on Windows.
> >
> > ("The Un...defeated... Defen...ding... Champion!")
> >
> > I hope to see LC9/10 further optimized. I love LC6, but you must
> understand I'm always entirely rooting for the latest version and hoping
> for it to wipe the floor with the others. When it wins, we all win.
> >
> > Plenty of methods and tricks to optimize LCS code, and the results may
> vary between releases and platforms, but engine optimization really is
> helpful. Its performance establishes the boundaries that we work within
> while scripting. When I get some time I'll run a new round of tests too and
> publish the results. Thanks again.
> >
> > Best wishes,
> >
> > Curry K.
>
>
> ___
> 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: Surprise...

[Bob Sneidar via use-livecode]

Wasn't it Unicode that slowed everything, especially string parsing down? 

Bob S


> On Aug 21, 2018, at 11:00 , Curry Kenworthy via use-livecode 
>  wrote:
> 
> Brian:
> 
> > I expanded my test stack and ran it
> > on the versions I had available.
> 
> Thanks for (among other things!) running these tests.
> 
> It's useful to see the item vs array turning point.
> 
> I also notice something else, if I read your result correctly: LC9 beats LC8 
> on these tests (that's a good sign!) but LC6 still dominates them all, in 
> this particular type of exercise that you've coded, on Mac. It was also the 
> winner in my previous tests on Windows.
> 
> ("The Un...defeated... Defen...ding... Champion!")
> 
> I hope to see LC9/10 further optimized. I love LC6, but you must understand 
> I'm always entirely rooting for the latest version and hoping for it to wipe 
> the floor with the others. When it wins, we all win.
> 
> Plenty of methods and tricks to optimize LCS code, and the results may vary 
> between releases and platforms, but engine optimization really is helpful. 
> Its performance establishes the boundaries that we work within while 
> scripting. When I get some time I'll run a new round of tests too and publish 
> the results. Thanks again.
> 
> Best wishes,
> 
> Curry K.


___
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: Surprise...

[Curry Kenworthy via use-livecode]

Brian:

> I expanded my test stack and ran it
> on the versions I had available.

Thanks for (among other things!) running these tests.

It's useful to see the item vs array turning point.

I also notice something else, if I read your result correctly: LC9 beats 
LC8 on these tests (that's a good sign!) but LC6 still dominates them 
all, in this particular type of exercise that you've coded, on Mac. It 
was also the winner in my previous tests on Windows.


("The Un...defeated... Defen...ding... Champion!")

I hope to see LC9/10 further optimized. I love LC6, but you must 
understand I'm always entirely rooting for the latest version and hoping 
for it to wipe the floor with the others. When it wins, we all win.


Plenty of methods and tricks to optimize LCS code, and the results may 
vary between releases and platforms, but engine optimization really is 
helpful. Its performance establishes the boundaries that we work within 
while scripting. When I get some time I'll run a new round of tests too 
and publish the results. Thanks again.


Best wishes,

Curry K.


___
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: Surprise...

[Brian Milby via use-livecode]

I expanded my test stack and ran it on the versions I had available.
Here's a couple of tests from each version:

macOS Sierra (10.12.6) on an iMac (Retina 5K, 27-inch, Late 2014) 4 GHz i7
9.0.1-rc-1 Business / 8.1.9 Business / 7.1.4 Indy / 6.7.11 Indy

34 10 11 10 34 5
LC9 item: 4562 / array: 12660 / 0.360348
LC8 item: 6175 / array: 13111 / 0.470979
LC7 item: 10994 / array: 11554 / 0.951532
LC6 item: 1278 / array: 4681 / 0.273019

340 10 11 10 34 500
LC9 item: 430179 / array: 125709 / 3.422022
LC8 item: 449724 / array: 131206 / 3.427618
LC7 item: 2473784 / array: 114818 / 21.545263
LC6 item: 258495 / array: 45592 / 5.669745

Notice that even in LC6, for this particular test (the original one), item
is faster (and by a bigger margin).  I don't think it is as much about the
speed of arrays per se, but knowing the data set and using the right
approach to get the optimal performance.  So, it is probably a reasonable
approach to use arrays first.  If you need to optimize for speed, this is
an area to consider.

Thanks,
Brian
___
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: Surprise...

[Brian Milby via use-livecode]

While this test may be valuable in comparing different versions of LC, I'm
not sure how useful the data is by itself.  I decided to run a test and see
what happened.  I defined 6 constants.  kA-kE for the size of each loop.
kF for the last line in tvar/element in the array.  To initialize, I just
made it simple and put 1,2,3...kX for the lines and T[1][1] = 1, T[1][2] =
2,... for the array.  To add an additional wrinkle, I added additional
lines to tvar such that the last line could be 5 or some other number.  I'm
on an iMac/Sierra running 9.0.1rc1.  Times are milliseconds.  First line is
the constant values.  First test is the original from the start of the
thread.

34 10 11 10 34 5
item: 4159 / array: 9718 / 0.427969

34 10 11 10 34 50
item: 5200 / array: 10346 / 0.50261

34 10 11 10 34 500
item: 36573 / array: 10298 / 3.551466

340 10 11 10 34 5
item: 81108 / array: 97007 / 0.836105

340 10 11 10 34 50
item: 213107 / array: 103755 / 2.053944

Notice not much relative difference between 5 and 50 lines in the original
test (but item did take 20% more time), but when I jumped it to 500 the
advantage shifted to array.  Notice how linear the array times are when the
outer loop is changed - compare test 1 to 4 and 2 to 5.  The number of
outer loops increased by a factor of 10 and the array time jumped by a
factor of 10.  Compare to the item where it was 20x and 40x.  This is where
the advantage of arrays lies - it is constant time to access, so the cost
is mainly a factor of the number of reads.

I also did the first and third test on 8.1.9 (slightly slower than 9):

34 10 11 10 34 5
item: 4828 / array: 10714 / 0.450625

34 10 11 10 34 500
item: 37806 / array: 11057 / 3.419191

If anyone wants the stack or code, let me know.

Thanks,
Brian

On Mon, Aug 20, 2018 at 4:03 PM, Curry Kenworthy via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> Hey Folks,
>
> Of course I'm interested in this thread. Always a big concern. Earlier
> this year, and last year, I was doing face-off competitions between
> LiveCode versions to test how optimization is faring.
>
> When I get time, after some other priorities and addon updates, I would
> like to do another round of cross-version testing to see who is the current
> champion. (IIRC, I think 6.7 was last time, for Windows.)
>
> Meanwhile
>
> jbv:
>
> > the same data on LC 6.5.2 desktop Mac, and arrays run 20% faster
> > than items... On LC9 server I get opposite results : items are
> > 2 times faster then arrays.
>
> 1. Try LC 6.5 desktop vs LC 9 desktop: how does that fare? And maybe LC 9
> desktop vs LC 9 server? I would like to distinguish LC 6/9 from LC
> desktop/server. Apples to apples testing, then conclusions are possible.
>
> 2. Sample code stack would be great.
>
> Mark T.:
>
> > I wrote a stack that demonstrated this and other concepts for
> > LC Mark directly. His Global talks called ‘Optimizing Your Code’
> > are partially based on some things we have been discussing.
>
> Optimizing our code is a good thing, and something I am paranoid about and
> specialize in helping people with. Optimizing LC's own code is also a good
> thing, and really the bigger question here perhaps for this thread!
>
> So...I'll be quietly following this thread. No time to participate yet,
> but will later.
>
> Best wishes,
>
> Curry Kenworthy
>
> Custom Software Development
> 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
>
___
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: Surprise...

[Curry Kenworthy via use-livecode]

Hey Folks,

Of course I'm interested in this thread. Always a big concern. Earlier 
this year, and last year, I was doing face-off competitions between 
LiveCode versions to test how optimization is faring.


When I get time, after some other priorities and addon updates, I would 
like to do another round of cross-version testing to see who is the 
current champion. (IIRC, I think 6.7 was last time, for Windows.)


Meanwhile

jbv:

> the same data on LC 6.5.2 desktop Mac, and arrays run 20% faster
> than items... On LC9 server I get opposite results : items are
> 2 times faster then arrays.

1. Try LC 6.5 desktop vs LC 9 desktop: how does that fare? And maybe LC 
9 desktop vs LC 9 server? I would like to distinguish LC 6/9 from LC 
desktop/server. Apples to apples testing, then conclusions are possible.


2. Sample code stack would be great.

Mark T.:

> I wrote a stack that demonstrated this and other concepts for
> LC Mark directly. His Global talks called ‘Optimizing Your Code’
> are partially based on some things we have been discussing.

Optimizing our code is a good thing, and something I am paranoid about 
and specialize in helping people with. Optimizing LC's own code is also 
a good thing, and really the bigger question here perhaps for this thread!


So...I'll be quietly following this thread. No time to participate yet, 
but will later.


Best wishes,

Curry Kenworthy

Custom Software Development
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: Surprise...

[jbv via use-livecode]

I made a test with the same loops and the same data on LC 6.5.2
desktop Mac, and arrays run 20% faster than items...
On LC9 server I get opposite results : items are 2 times faster then arrays.

As said in my original post, AFAIR U have always used arrays instead
of items & lines because it has always been faster, even with
multidimensional
arrays...


On Mon, August 20, 2018 9:57 pm, Alex Tweedly via use-livecode wrote:
> Not really a huge surprise ... access to chunks such as 'item' and
> 'line' are (potentially) slow when you are searching relatively large
> strings. So the archetypal example
>
> repeat with i = 1 to N    get line i of tBigString
> end repeat
>
> can get slow if N is large, because of repeatedly scanning over large
> leading sub-strings to get to line 'i'.
>



___
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: Surprise...

[Alex Tweedly via use-livecode]

Not really a huge surprise ... access to chunks such as 'item' and 
'line' are (potentially) slow when you are searching relatively large 
strings. So the archetypal example


repeat with i = 1 to N
   get line i of tBigString
end repeat

can get slow if N is large, because of repeatedly scanning over large 
leading sub-strings to get to line 'i'.


In your case here, although we don't know how long the lines are (or how 
many items they have in them), the number of lines is very small  (i.e. 
line 1 up to line 4), so the amount of processing needed to scan/skip 
over the first few lines is very small - even though it's done often.


If you have some sample data, or gave some characteristics of the data, 
we could perhaps comment more.


-- Alex.


On 20/08/2018 10:00, jbv via use-livecode wrote:

Hi list,

I have the following script :

repeat with a = 1 to 34
  repeat with b = 1 to 10
   repeat with c = 1 to 11
repeat with d = 1 to 10
 repeat with e = 1 to 34
  --get item a of line 1 of tvar & tab & item b of line 2 of tvar & tab
& item c of line 3 of tvar & tab & item d of line 4 of tvar & tab &
item e of line 5 of tvar
  --get T[1][a] & tab & T[2][b] & tab & T[3][c] & tab & T[4][d] & tab &
T[5][e]
 end repeat
end repeat
   end repeat
  end repeat
end repeat

When I run these nested loops with the line "get item a of line 1 of
tvar...",
it is twice faster than with the line "get T[1][a]...".
This a surprise to me because I have used arrays for years to speed up
things, and AFAIK it takes forever to count items and lines at each repeat
iteration...
Or am I missing something ?
This is on LC9 server, on-rev account.

Best,
jbv


___
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: Surprise...

[Mark Talluto via use-livecode]

I wrote a stack that demonstrated this and other concepts for LC Mark directly. 
His Global talks called ‘Optimizing Your Code’ are partially based on some 
things we have been discussing.

Best regards,

Mark Talluto
livecloud.io 
nursenotes.net 
canelasoftware.com 


> On Aug 20, 2018, at 9:54 AM, Tom Glod via use-livecode 
>  wrote:
> 
> not loving the sound of all this.  has there been any word about the
> reasons why array access has slowed down as much as it has?
> 
> On Mon, Aug 20, 2018 at 12:11 PM, Alex Tweedly via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Hi Malte,
>> 
>> sounds like something I would normally have jumped on :-)
>> 
>> And I don't offhand remember a thread like this started by you - can you
>> give me more of a pointer to when it was or what the subject line(s) were ?
>> 
>> Thanks
>> 
>> Alex.
>> 
>> P.S. please try not to be demotivated by this kind of problem - I'm sure
>> if we can investigate it from the "outside" then LC will be able to look at
>> it from th "inside" and hopefully come up with some answer. SO let's have
>> a(nother) look at the thread 
>> 
>> 
>> 
>> 
>> On 20/08/2018 15:25, Malte Pfaff-Brill via use-livecode wrote:
>> 
>>> Hi jbv,
>>> 
>>> Same boat…
>>> 
>>> And it is not the repeat variant has increased, but array access slowed
>>> down (a lot) a while back I was doing benchmarks on this. Thread should
>>> still be buried somewhere here. As not many jumped on the problems I faced
>>> with array access, I somewhat gave up, which is a bummer, as it affected so
>>> many of my libs and custom controls. Also the data grid.
>>> It started with the rewrite. Still hoping for optimization. This bugs me
>>> so much that I am effectively no longer motivated to script. *sigh*
>>> 
>>> 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
>> 
> ___
> 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: Surprise...

[Tom Glod via use-livecode]

not loving the sound of all this.  has there been any word about the
reasons why array access has slowed down as much as it has?

On Mon, Aug 20, 2018 at 12:11 PM, Alex Tweedly via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi Malte,
>
> sounds like something I would normally have jumped on :-)
>
> And I don't offhand remember a thread like this started by you - can you
> give me more of a pointer to when it was or what the subject line(s) were ?
>
> Thanks
>
> Alex.
>
> P.S. please try not to be demotivated by this kind of problem - I'm sure
> if we can investigate it from the "outside" then LC will be able to look at
> it from th "inside" and hopefully come up with some answer. SO let's have
> a(nother) look at the thread 
>
>
>
>
> On 20/08/2018 15:25, Malte Pfaff-Brill via use-livecode wrote:
>
>> Hi jbv,
>>
>> Same boat…
>>
>> And it is not the repeat variant has increased, but array access slowed
>> down (a lot) a while back I was doing benchmarks on this. Thread should
>> still be buried somewhere here. As not many jumped on the problems I faced
>> with array access, I somewhat gave up, which is a bummer, as it affected so
>> many of my libs and custom controls. Also the data grid.
>> It started with the rewrite. Still hoping for optimization. This bugs me
>> so much that I am effectively no longer motivated to script. *sigh*
>>
>> 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
>
___
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: Surprise...

[Alex Tweedly via use-livecode]

Hi Malte,

sounds like something I would normally have jumped on :-)

And I don't offhand remember a thread like this started by you - can you 
give me more of a pointer to when it was or what the subject line(s) were ?


Thanks

Alex.

P.S. please try not to be demotivated by this kind of problem - I'm sure 
if we can investigate it from the "outside" then LC will be able to look 
at it from th "inside" and hopefully come up with some answer. SO let's 
have a(nother) look at the thread 




On 20/08/2018 15:25, Malte Pfaff-Brill via use-livecode wrote:

Hi jbv,

Same boat…

And it is not the repeat variant has increased, but array access slowed down (a 
lot) a while back I was doing benchmarks on this. Thread should still be buried 
somewhere here. As not many jumped on the problems I faced with array access, I 
somewhat gave up, which is a bummer, as it affected so many of my libs and 
custom controls. Also the data grid.
It started with the rewrite. Still hoping for optimization. This bugs me so 
much that I am effectively no longer motivated to script. *sigh*

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: Surprise...

[Malte Pfaff-Brill via use-livecode]

Hi jbv,

Same boat… 

And it is not the repeat variant has increased, but array access slowed down (a 
lot) a while back I was doing benchmarks on this. Thread should still be buried 
somewhere here. As not many jumped on the problems I faced with array access, I 
somewhat gave up, which is a bummer, as it affected so many of my libs and 
custom controls. Also the data grid.
It started with the rewrite. Still hoping for optimization. This bugs me so 
much that I am effectively no longer motivated to script. *sigh*

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: Surprise...

[dunbarxx via use-livecode]

Hi.

Not sure the code snippet you supplied is complete. There are no variables
"T" or "tVar", and so all your nested repeat loops are just time expenders.
In other words, you could have just:

repeat 100

That said, it seems that assembling the nonexistent array variable
repeatedly is slower that assembling the nonexistent ordinary variable
repeatedly. Others may comment on this.

But you have not really "used" an array, only built one, er , repeatedly, if
you understand what I mean. Is that what you were concerned with?

Craig Newman



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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

Surprise...

[jbv via use-livecode]

Hi list,

I have the following script :

repeat with a = 1 to 34
 repeat with b = 1 to 10
  repeat with c = 1 to 11
   repeat with d = 1 to 10
repeat with e = 1 to 34
 --get item a of line 1 of tvar & tab & item b of line 2 of tvar & tab
& item c of line 3 of tvar & tab & item d of line 4 of tvar & tab &
item e of line 5 of tvar
 --get T[1][a] & tab & T[2][b] & tab & T[3][c] & tab & T[4][d] & tab &
T[5][e]
end repeat
   end repeat
  end repeat
 end repeat
end repeat

When I run these nested loops with the line "get item a of line 1 of
tvar...",
it is twice faster than with the line "get T[1][a]...".
This a surprise to me because I have used arrays for years to speed up
things, and AFAIK it takes forever to count items and lines at each repeat
iteration...
Or am I missing something ?
This is on LC9 server, on-rev account.

Best,
jbv


___
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: A little surprise... and Happy New Year 2011!

[Medard]

Medard  wrote:

> Robert Mann  wrote:
> 
> > have a good day, bonne journée.. et fetes!
> 
> "I wish you a Merry Christmas and Happy New Year" :-)
> 
> Nonetheless, if Livecode could standardize on UTF-8...

Watching "charset" in the dictionary, it cannot be changed, only read...
The charset is set accordingly to the platform, and is only changed when
the stack is ported to another platform...

___
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: A little surprise with LiveCode and On-Rev

[Medard]

Robert Mann  wrote:

> have a good day, bonne journée.. et fetes!

"I wish you a Merry Christmas and Happy New Year" :-)

Nonetheless, if Livecode could standardize on UTF-8...

___
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: A little surprise with LiveCode and On-Rev

[Robert Mann]

Well.. I do the following :

- write html and .irev files using on-rev editor (uses mac roman)
- then edit the files with wrangler and saving the files using UTF8 no BOM
- from then I can edit the html files on both (on-rev editor or wrangler)

==> no BOM is important otherwise you get a strange char at the begining of
the file and the file may not be recognized as an irev file...

Sure it would have been a little bit simpler to provide an on-rev editor
working in UTF8 straight from the box! 
(bad news THERE IS NO PREF. TO SET ON the on-rev editor as far as char set
is concerned)

Now it also easy to make an ftp editori with livecode that can dialog in UTF
8 with on-rev straight ahead!
have a good day, bonne journée.. et fetes!
-- 
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/A-little-surprise-with-LiveCode-and-On-Rev-tp3094576p3094891.html
Sent from the Revolution - User mailing list archive at Nabble.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

A little surprise with LiveCode and On-Rev

[Medard]

Again, some musing with On-Rev ;-)

I made a simple "blog" with my reading notes around the web
[mostly in french]



As for now I am putting together pieces to create one file, a head, a
body, and a footer

The body itself is made from concatenating html files included in a
dedicated folder

For the first times, I made that by hand.

Now I am trying to build them via a dedicated LiveCode stack, and for
now that works properly -- excepted for the accented chars, which are
replaced by  ;->

I took a look at the bottom of the TextWrangler page, to notice that the
charset was not the good one, it was "Mac OS Roman"instead of "UTF-8 no
BOM"!

So, it seems that files written by LiveCode, at least on a Mac, have a
"Mac OS Roman" charset by default...

Maybe there is some Preference to fix that, but for now I don't where...

___
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