Slow LC 9 Performance - Test Stack, Video, QA Report

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode

LiveCode 9 (as of 9.0.1 RC 3) is significantly slower than LiveCode 6.7
in a variety of tasks. This is a huge problem, it affects many of the
projects I'm doing, and I'm sure others are in the same boat. Fellow
boat members: please join my bug report/feature request below!

The slowdown can be demonstrated both in test code and in real-world
applications. The problem(s) may be in a specific area, but the actual
effects on running code are widespread and fairly general, impacting
multiple areas in my testing from math and loops to text, chunks, and
arrays. I am posting some resources tonight to help draw attention and
evaluate this problem, and requesting that LiveCode 9 be optimized to
achieve at least speed parity with LiveCode 6 in these areas.

(I am encouraged that some LC engine optimization impacting arrays is
already underway by LC Mark W., but I want to emphasize and prove beyond
doubt that several areas are affected and not only arrays. Therefore I
hope this bug reports and test stack(s) will help to confirm whether the
optimizations underway also solve the other areas, or whether those
areas need further separate optimization.)

Resources below.

A) QA Bug or Feature Request:

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

Report on this problem (which negatively impacts end users for existing
features) with 2 recipes and downloads (test demo code and real world
application). If your own app or code is affected by LC 9 performance,
please add your CC and a comment.

B) YouTube video: LC Version "Showdown"

https://youtu.be/8uhOem46VXg

Thorough demonstration and discussion of my tests and the results,
pitting LiveCode 6.7 against the latest release of LiveCode 9 in several
tasks that evaluate loops, math, text appends, array access, item
chunks, and text replace.

JavaScript code is also tested and provided to provide additional
reference. (Thanks Richard G. for the suggestion! Very interesting results.)

C) LC Version "Showdown" demo stack:

http://curryk.com/showdown.zip

The stack used in the video. See and test the code for yourself.
Compares 6.7 and LC 9 (or others, you can use 7 or 8 too) for speed in
loops, math, text appends, array access, item chunks, and text replace.
(Also has effects used in video competition; this issue has been on my
to-do list for some time, and I wanted a stack that looks good, makes
comparisons quick and easy, and can serve as a useful platform for
current and future tests.)

Some buttons have right-click or shift-click alternatives, these are
listed in tooltips. If desired, paste the JavaScript (which is
automatically placed on the clipboard after each test) into js.do or
another web page to compare the JS speed to LC.

BTW, I'm only days away from a new WordLib release and have been doing a
great deal of cross-version testing with it too. That, and Mark's array
effort, were what prompted me to make extra time for this and get it
posted today. WordReport is also due for an update, so is WordOut, and
performance is something I take very seriously. Beyond that, I place the
highest importance on all client app performance too.

WordLib code uses a variety of the code areas mentioned here, some
arrays but not relying on them heavily in the work, so I consider it a
good balanced real-world example of the impact of LC 9 performance. It's
pretty hard-hit for big files, because many or most operations in LC 9
take 2x, 3x, or 4x the time compared to LC 6. (In fact I think it's
somewhat challenging to find substantial code that is NOT hit by LC 9
performance. I found one example in 9's favor to include in the showdown
stack and video.)

So again I wanted to emphasize it's not just arrays - that is proven
here beyond any doubt in downloadable code and on video. I hope the
array optimizations might help the other areas too, but if not, they
need attention. Thank you! :)

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.com/


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode
Hey Curry, I really appreciate you doing this video / post , hopefully it
will have the intended outcome.  I must say I am in production with 9 and
have been satisfied with the performance so far, but i can't go back to
compare.... so I guess I am happy to hear that there is a boost still to
come.

Thanks again for the efforts.

On Wed, Sep 5, 2018 at 12:46 AM Curry Kenworthy via use-livecode <
[hidden email]> wrote:

>
> LiveCode 9 (as of 9.0.1 RC 3) is significantly slower than LiveCode 6.7
> in a variety of tasks. This is a huge problem, it affects many of the
> projects I'm doing, and I'm sure others are in the same boat. Fellow
> boat members: please join my bug report/feature request below!
>
> The slowdown can be demonstrated both in test code and in real-world
> applications. The problem(s) may be in a specific area, but the actual
> effects on running code are widespread and fairly general, impacting
> multiple areas in my testing from math and loops to text, chunks, and
> arrays. I am posting some resources tonight to help draw attention and
> evaluate this problem, and requesting that LiveCode 9 be optimized to
> achieve at least speed parity with LiveCode 6 in these areas.
>
> (I am encouraged that some LC engine optimization impacting arrays is
> already underway by LC Mark W., but I want to emphasize and prove beyond
> doubt that several areas are affected and not only arrays. Therefore I
> hope this bug reports and test stack(s) will help to confirm whether the
> optimizations underway also solve the other areas, or whether those
> areas need further separate optimization.)
>
> Resources below.
>
> A) QA Bug or Feature Request:
>
> https://quality.livecode.com/show_bug.cgi?id=21561
>
> Report on this problem (which negatively impacts end users for existing
> features) with 2 recipes and downloads (test demo code and real world
> application). If your own app or code is affected by LC 9 performance,
> please add your CC and a comment.
>
> B) YouTube video: LC Version "Showdown"
>
> https://youtu.be/8uhOem46VXg
>
> Thorough demonstration and discussion of my tests and the results,
> pitting LiveCode 6.7 against the latest release of LiveCode 9 in several
> tasks that evaluate loops, math, text appends, array access, item
> chunks, and text replace.
>
> JavaScript code is also tested and provided to provide additional
> reference. (Thanks Richard G. for the suggestion! Very interesting
> results.)
>
> C) LC Version "Showdown" demo stack:
>
> http://curryk.com/showdown.zip
>
> The stack used in the video. See and test the code for yourself.
> Compares 6.7 and LC 9 (or others, you can use 7 or 8 too) for speed in
> loops, math, text appends, array access, item chunks, and text replace.
> (Also has effects used in video competition; this issue has been on my
> to-do list for some time, and I wanted a stack that looks good, makes
> comparisons quick and easy, and can serve as a useful platform for
> current and future tests.)
>
> Some buttons have right-click or shift-click alternatives, these are
> listed in tooltips. If desired, paste the JavaScript (which is
> automatically placed on the clipboard after each test) into js.do or
> another web page to compare the JS speed to LC.
>
> BTW, I'm only days away from a new WordLib release and have been doing a
> great deal of cross-version testing with it too. That, and Mark's array
> effort, were what prompted me to make extra time for this and get it
> posted today. WordReport is also due for an update, so is WordOut, and
> performance is something I take very seriously. Beyond that, I place the
> highest importance on all client app performance too.
>
> WordLib code uses a variety of the code areas mentioned here, some
> arrays but not relying on them heavily in the work, so I consider it a
> good balanced real-world example of the impact of LC 9 performance. It's
> pretty hard-hit for big files, because many or most operations in LC 9
> take 2x, 3x, or 4x the time compared to LC 6. (In fact I think it's
> somewhat challenging to find substantial code that is NOT hit by LC 9
> performance. I found one example in 9's favor to include in the showdown
> stack and video.)
>
> So again I wanted to emphasize it's not just arrays - that is proven
> here beyond any doubt in downloadable code and on video. I hope the
> array optimizations might help the other areas too, but if not, they
> need attention. Thank you! :)
>
> Best wishes,
>
> Curry Kenworthy
>
> Custom Software Development
> LiveCode Training and Consulting
> http://livecodeconsulting.com/
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode

Tom:

 > Thanks again for the efforts.

You're welcome! Glad you liked it.

I guess I should have mentioned that the big slowdown in LC 9 is not
something that people will notice with extremely short code like go next
card or put 12 into field 1. This is about substantial code (loops or
many operations) or working with data. The speed of the code!

Here is a complete table of my test results:

http://curryk.com/lc-version-showdown-results.png

Some highlights:

LC 9 is 3x slower than LC 6 (and 49 times slower than JS) on a loop with
math.

LC 9 is 2x to 4.5x slower than LC 6 on reading comma-delimited items and
appending them to a text.

LC 9 is 2.4x slower than LC 6 (and 106x slower than JS) on accessing
array elements and appending them to a text.

LC 9 holds its own against LC 6 (but is 4x slower than JS) on most
big-text case-insensitive operations.

LC trumps JS on big-text replace with one-char search string.

Remember, we don't want to go back to LC 6. That's not the idea. We want
progress. We want to go forward effectively into the bright future of
LC, and that future should include good performance! Much brighter.

LC 6 comes into the picture for my testing because to measure
performance, we must have a reference point. Anything divided by itself
= 1. :)

So LC 6 is a useful speed reference. It also represents the actual speed
my own code attained previously. Yes, I like speed. Hate to lose it. I'm
using 9 every day now, and that's why I have all this test data. That's
why I've noticed the issues. Significantly slower is usually not a good
thing. Progress is, and optimization is too! Optimization is an
important component of progress.

(The JS is thrown in as additional reference, and may suggest
opportunities for further improvement in some of those areas, but my
main concern right now is keeping LC running at least as fast as it has
been, which currently boils down to 9 vs 6.)

Hope this info was useful!

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.com/


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode

PS - one more test that I will add later to the "showdown" stack:

"Root Loops" tested both repeats and math (hence the name) but I hadn't
benchmarked an empty loop. I should have done that to try and separate
math from loops to the extent possible.

(on native Windows 10 6th Gen i3)

repeat with i=1 to 1234567
end repeat

LC 6.7.11: 45 ms
LC 9.0.0: 125 ms
9 vs 6: 2.8x slower

repeat 1234567
end repeat

LC 6.7.11: 15 ms
LC 9.0.0: 20 ms
9 vs 6: 1.3x slower

Could be significant, yes?

Best wishes,

Curry K.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode
totally weird!



On Wed, Sep 5, 2018 at 10:03 PM Curry Kenworthy via use-livecode <
[hidden email]> wrote:

>
> PS - one more test that I will add later to the "showdown" stack:
>
> "Root Loops" tested both repeats and math (hence the name) but I hadn't
> benchmarked an empty loop. I should have done that to try and separate
> math from loops to the extent possible.
>
> (on native Windows 10 6th Gen i3)
>
> repeat with i=1 to 1234567
> end repeat
>
> LC 6.7.11: 45 ms
> LC 9.0.0: 125 ms
> 9 vs 6: 2.8x slower
>
> repeat 1234567
> end repeat
>
> LC 6.7.11: 15 ms
> LC 9.0.0: 20 ms
> 9 vs 6: 1.3x slower
>
> Could be significant, yes?
>
> Best wishes,
>
> Curry K.
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
Curry Kenworthy wrote:

> repeat with i=1 to 1234567
> end repeat

Is that an actual test from the stack?

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 ____________________________________________________________________
 [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode

Richard:

 > Is that an actual test from the stack?

The stack had (essentially) this:

repeat with i=1 to 1234567
   add sqrt(i) to n
end repeat

(LC 9 is 2.8 times slower.)

So my latest experiment removed the inside line:

repeat with i=1 to 1234567
end repeat

(LC 9 is 2.8 times slower, again.)

Have a go? It's all there to see and test!

http://curryk.com/showdown.zip

Best wishes,

Curry K.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
How did you do the JavaScript (in browser?) and
how did you do the timing?

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode

hh:

 > How did you do the JavaScript (in browser?)

I wrote the JS code by hand, scripted the stack to copy it to clipboard
after each test, and ran it on js.do

 > and how did you do the timing?

It's in the test code; download and all will be revealed! ;)

Later I will add the empty loop test and a math-intensive test
variation. Similar results though; LC 9 is 2.8x slower for empty loop
and about 2x slower for math-intensive.

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.com/

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
Curry,

sorry I overlooked the post with your download link

> http://curryk.com/showdown.zip

This is a *fine* comparison stack.

You could think about adding for LC 8/9 a browser widget and in
handler "work done", instead of copying to the clipboard,

set htmltext of widget "browser" to the cJS of the target

By that it is another example for using JS via a browser widget
and shows in which usecases it is worth to "outsource"
lengthy computations (walking through imagedata is also one).



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode

Hello Everyone,

Updated stack and more complete results - let me know if you get
something very different on your machine.

I've added two additional LC benchmark test variations to the "showdown"
test stack. That gives it empty loop (with i) and math-intensive options
in the "root loops" button. I felt those were needed to round out the
tests and cover more areas.

(It has only 3 buttons, but each button has right-click and shift-click
variations on the general test, explained in tooltips. Total of 12
benchmarks.)

http://curryk.com/LC-Version-Showdown-B.zip

Also the result times (in ms) are now saved to a global variable with
descriptive keys. I used that to crank out a comprehensive report of the
benchmark results on both Mac and Windows:

http://curryk.com/lc-version-showdown-win-mac.png

http://curryk.com/lc-version-showdown-win-mac.pdf

As you can see, in many areas LiveCode is significantly slower (1.6x,
1.8x, 2x, 3x, 4x) than it was 2 years ago.

Mac and Windows is a bit different, at least on my machines. Windows was
hit worse on loops, Mac slowed down more on arrays. But the overall
pattern is similar; except for some text operations, LC has become
noticeably slower than it was before.

For those of us who have serious and substantial code - big problem!
Understandable during the LC 7 refactoring, but now it's hopefully time
to start tightening things up again.

(And no, I certainly don't consider performance a "use-case" for
converting any serious blocks of code to JS or other languages! I can
write JS well enough as you see, but if I wanted to write all my
important code in JS, I would be there, not here. I take LC coding very
seriously, maintain and produce a lot of extremely high-quality LCS
code, and I consider LC a serious platform for coding. I want my
important code, my serious code, right here in LCS. And I want to see LC
gain popularity among coders. Trust me, performance is your friend and
good things follow it, so any attention to performance should pay for
itself.)

Anyway, I hope this info and effort helps the cause and helps LC! There
are probably a number of important areas I missed, but it is a rather
extensive benchmark already and does touch on a variety of the basics.
That's all the tests I have time to design at the moment, must get back
to other code, but this stack will make it fairly easy to add more tests
in future and evaluate new versions on current tests. I hope to follow
up with a satisfying performance "smackdown" where a new LC 9 or 10 mops
the floor with the competition! :)

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.com/



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode
On 09/06/2018 03:15 PM, Curry Kenworthy via use-livecode wrote:

>
> Hello Everyone,
>
> Updated stack and more complete results - let me know if you get
> something very different on your machine.
>
> I've added two additional LC benchmark test variations to the "showdown"
> test stack. That gives it empty loop (with i) and math-intensive options
> in the "root loops" button. I felt those were needed to round out the
> tests and cover more areas.

*Very* interesting. Thanks for the benchmark stack.
I'm seeing similar results to yours here on linux Mint 17.3, with the
exception of Append 1280 item texts, where I'm seeing LC9 quite a bit
faster than LC6.7.11. It's quite consistent across multiple runs. This
may be due to the fact that LC6 is 32-bit and I'm comparing it with a
64-bit LC9. For appending 5 item texts, I see a 3x slowdown in LC9,
similar to your results.

Append 345678 Items texts (of 1280):
LC6.7.11 (32-bit):  4894 ms
LC9.01rc3 (64-bit): 3271 ms

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode

Mark:

 > For appending 5 item texts, I see a 3x slowdown in LC9,
 > similar to your results.

Thanks for sharing your Linux results!

So that means on 3 different platforms (Mac, Win, Linux) using item
chunks is 3x to 4x slower in LiveCode today than it was 2 years ago, for
a short list of items.

(And I just realized that some Mac people may have misunderstood that
all this was just another Mac/Win type comparison, so I'll state it
again clearly from a Mac-centric perspective.)

LC on Mac today is 3 times slower than it was two years ago for arrays
and items, and 2 times slower for math! At least on my Mac, assuming it
holds true for your chip too. So we are all in this performance boat
together, no matter your OS preference. You're affected.

Moreover (as I demo'd in the video) using item chunks is slower in
LiveCode today than using an array was 2 years ago! The old speed of
items blew it away. That may surprise some of the people thinking
they'll just use items; the ultra-fast option doesn't exist anymore.

I'm very happy that arrays already are on LC's official radar, because
they are extremely important and they are currently 2x-3x slower. That
will help. Probably noticed, and on the radar, because Mac was
disproportionately affected! Mac Mac Mac. :)

But attention Mac people: Mac is every bit as affected (3.3x slower than
before) by those slower chunks for a small list of items. (Big lists
too, on Mac AFAIK.) So fixing arrays is only part of the solution. Items
are pretty important too, especially when they are being emphasized as a
route for optimizing code. Math and loops help too.

 > Append 345678 Items texts (of 1280):
 > LC6.7.11 (32-bit):  4894 ms
 > LC9.01rc3 (64-bit): 3271 ms

Nice to know that bright spot for Linux on the bigger lists and 64-bits!
Mac and Windows performance both got 1.7 times worse on those, at least
on my machines. I appreciate you testing it.

Best wishes,

Curry K.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode
On 09/07/2018 01:04 PM, Curry Kenworthy via use-livecode wrote:

> Nice to know that bright spot for Linux on the bigger lists and 64-bits!
> Mac and Windows performance both got 1.7 times worse on those, at least
> on my machines. I appreciate you testing it.

I misread some of my data yesterday, and there are actually a few other
places where LC9 is faster than LC6.7 on linux. And just for fun I
loaded a 32-bit LC9 so it's a more fair comparison.

Append 345678 Items texts (of 1280)
32bitLC6: 4894
32bitLC9: 3895
64bitLC9: 3271

Text Maxed
32bitLC6: 765 : 1018
32bitLC9: 494 : 1341
64bitLC9: 484 : 1469
(casesensitive)
32bitLC6: 760:   928
32bitLC9: 504 : 1308
64bitLC9: 494 : 1285
single-char search text
32bitLC6: 760 : 793
32bitLC9: 504 : 879
64bitLC9: 493 : 804
single-char search text (casesensitive)
32bitLC6: 761 : 743
32bitLC9: 504 : 817
64bitLC9: 511 : 797

Otherwise (math especially) LC6 is much faster.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode
Just a quick wild thought: Are the math routines doing unnecessary unicode interpretation?
.Jerry

> On Sep 7, 2018, at 6:11 PM, Mark Wieder via use-livecode <[hidden email]> wrote:
>
> Otherwise (math especially) LC6 is much faster.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode
On 09/07/2018 06:18 PM, Jerry Jensen via use-livecode wrote:
> Just a quick wild thought: Are the math routines doing unnecessary unicode interpretation?

That's my guess as well.
Doing type conversion on the strings-that-are-not-strings and then
getting to the math functions.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode

> On Sep 7, 2018, at 6:27 PM, Mark Wieder via use-livecode <[hidden email]> wrote:
>
> On 09/07/2018 06:18 PM, Jerry Jensen via use-livecode wrote:
>> Just a quick wild thought: Are the math routines doing unnecessary unicode interpretation?
>
> That's my guess as well.
> Doing type conversion on the strings-that-are-not-strings and then getting to the math functions.

Or even unnecessary multiple conversions within a complex math expression…
.Jerry


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode

Jerry:

 > Are the math routines doing unnecessary unicode interpretation?

Mark:

 > Doing type conversion on the strings-that-are-not-strings
 > and then getting to the math functions.

You guys might be right, but I doubt it. Here's one reason why. I took
some care to make the math test a true math test.

Notice in Root Loops:

local sQty=1234567
add 0 to sQty --> make it a true number*
put 0 into n
repeat with i=1 to sQty
   add sqrt(i) to n
end repeat

* So sQty is already binary when the loop starts.

The "1" is a string, but that only happens once and shouldn't matter.
(In fact I started out with stuff like t1 just to be sure, and 0+0 into
n, but it made no difference so I took it out.

After one loop at most, i and n are now binary and should stay that way.
Sqrt is acting upon i (binary), adding the result (binary) to n (binary)
and comparing i to sQty (binary) so in theory no conversion should be
taking place until the repeat is over. So in theory we're really testing
the math between versions and not the conversion.

Second reason: because (perhaps ironically) it turns out the text
portions of LC, other than chunks, are actually performing better on
tests than other parts. It's not my place to speculate, but maybe the
attention given to the text handling code during Unicode did a lot of
good! But I don't want to speculate too much; I'd better stick more to
the stats. :)

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.com/

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode

Me:

 > I took some care to make the math test a true math test.

P.S. - I was careful about binary optimization for the original Root
Loops math test, but the alternate shift-click test I added later (big
calculations) didn't have that.

Doing so makes hardly any difference for LC6, but it does help LC9 quite
a bit. It brings the big calculations result on Windows down from 2x to
1.5x slower on my computer. That helps to separate the maths from the
loops. Very good point Jerry/Mark; whether it's due to Unicode or not,
conversion on 9 may be slower!

But even with conversion happening inside a loop, the unoptimized big
math was 2x slower whereas the main Root Loops test (always binary
optimized) is 2.7x slower, as is an empty loop with i.

So the loop itself, or especially the "with i" portion of it, might be
part of the problem. I had previously tested a loop with no i (repeat
sQty) and it was only 1.3 times slower. Hmmmmm. That could leave the
incrementing and the comparison to sQty. One of those could be a
culprit, or collectively maybe all 3 play a part; 1.3 ^ 3 = 2.2.

Unfortunately I don't have any time to pursue more tests right now, plus
I was determined at first to only provide the results and not speculate
too much on causes. Breaking my rule here. :)

But I hope we can get some great engine performance going soon, one way
or another. Run well-optimized scripts on a very fast engine and we'd be
blazing along nicely!

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://livecodeconsulting.com/


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Slow LC 9 Performance - Test Stack, Video, QA Report

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
On 09/07/2018 06:55 PM, Curry Kenworthy via use-livecode wrote:

> You guys might be right, but I doubt it. Here's one reason why. I took
> some care to make the math test a true math test.
>
> Notice in Root Loops:
>
> local sQty=1234567
> add 0 to sQty --> make it a true number*

I could be wrong, but I'm not convinced that's what actually happens.
So if the next line is

if sQty = "1234567"

by your account that should be a runtime error because it's a comparison
between a number and a string? Or does the comparison operator somehow
convert the number back to a string to compare the two?

I'm suspicious enough of the sleight-of-hand that underpins the use of
unquoted string literals not to trust the easy answers, and to think
that under the hood in the engine everything at the script level is an
MCString until necessarily converted internally for computation. And
then back again.

But just guessing.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12