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