Re: Slow LC 9 Performance - Test Stack, Video, QA Report
PS - Alex, I see that when I modified the code I moved the timer and ended up timing the loading of the files, whereas you were timing the data comparison after loading! :) I'll try that tomorrow night. Good area for testing, interesting results. 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: Slow LC 9 Performance - Test Stack, Video, QA Report
Alex: > And I was encouraged to try a quick test - which turned out to be > a counter-example. LC9 is 4x faster than LC6 on this little test > (consistently over different photos). Thanks! This is a good test. Any counter-examples are great since they narrow down the problem areas. However, now the tricky part... I tried this and got the same result, first timed LC 6, then LC 9 was faster. But then (for variety) if I tested LC 9 first, then 6 was faster! So I think OS caching may be playing a role. If so, that adds a new level of challenge to the testing and the tester. :) If I retest the same files repeatedly (both cached) then LC 6 wins, on Windows 10, for both. LC 9 was 2x slower for URL and 1.5 times for open/read. (I had modified the code slightly to let me choose a folder full of pics and choose URL or open/read, loading all the files with the selected method and adding up the total num of bytes.) How about your code - if you test LC 9 first on new files, or the same files repeatedly with both LCs, is LC 9 still the winner? 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: Slow LC 9 Performance - Test Stack, Video, QA Report
As to speed comparisons with LC 9: Compared to LC 8, LC Builder of LC 9 has an increase of 50-120% in speed. (Seen with timings when creating an LCD-scroller widget and an image widget). ___ 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: Slow LC 9 Performance - Test Stack, Video, QA Report
I have observed this also. I tested by putting an animated gif in front of a
extremely hi-res test image. LC 8 choked but LC9 did not even breath hard.
Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net
-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of
Alex Tweedly via use-livecode
Sent: Tuesday, September 11, 2018 5:54 PM
To: use-livecode@lists.runrev.com
Cc: Alex Tweedly
Subject: Re: Slow LC 9 Performance - Test Stack, Video, QA Report
And I was encouraged to try a quick test - which turned out to be a
counter-example. LC9 is 4x faster than LC6 on this little test (consistently
over different photos).
*on mouseUp
local tData1, tData2, time1, temp
put URL ("binfile:/Users/alextweedly/Dropbox
(Personal)/Pictures/2016/101_0818/IMGP0021.JPG") into tData1
put URL ("binfile:/Users/alextweedly/Dropbox
(Personal)/Pictures/2016/101_0818/IMGP0021.JPG") into tData2
-- put tData1 into tData2
put the millisecs into time1
repeat 50 times
if tData1 = tData2 then
-- add 1 to temp
end if
end repeat
put the number of bytes in tData1 && the millisecs - time1 && temp into msg
end mouseUp
(it's an 18Mb image file).
Alex.
*
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Slow LC 9 Performance - Test Stack, Video, QA Report
On 11/09/2018 16:59, Curry Kenworthy via use-livecode wrote:
Interesting considerations. Whatever the causes, LC 9 needs a little
work to get back in shape. Get off the couch and start running again!
:) There are so many different tasks where 9 is underperforming; any
code with repeat loops, chunks, arrays, or math is likely to be slow
compared to where we were 2 years ago. Mac is affected just as badly
as Windows. Linux is affected too.
BTW Bob, Mark, Jerry, and others following this thread - could you
also add your CC to the bug report in the QA center?
Done.
And I was encouraged to try a quick test - which turned out to be a
counter-example. LC9 is 4x faster than LC6 on this little test
(consistently over different photos).
*on mouseUp
local tData1, tData2, time1, temp
put URL ("binfile:/Users/alextweedly/Dropbox
(Personal)/Pictures/2016/101_0818/IMGP0021.JPG") into tData1
put URL ("binfile:/Users/alextweedly/Dropbox
(Personal)/Pictures/2016/101_0818/IMGP0021.JPG") into tData2
-- put tData1 into tData2
put the millisecs into time1
repeat 50 times
if tData1 = tData2 then
-- add 1 to temp
end if
end repeat
put the number of bytes in tData1 && the millisecs - time1 && temp
into msg
end mouseUp
(it's an 18Mb image file).
Alex.
*
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Slow LC 9 Performance - Test Stack, Video, QA Report
Mark Wieder: > I'm suspicious enough of the sleight-of-hand that underpins the > use of unquoted string literals not to trust the easy answers, ... Bob S: > That's the first thing I thought. Interesting considerations. Whatever the causes, LC 9 needs a little work to get back in shape. Get off the couch and start running again! :) There are so many different tasks where 9 is underperforming; any code with repeat loops, chunks, arrays, or math is likely to be slow compared to where we were 2 years ago. Mac is affected just as badly as Windows. Linux is affected too. BTW Bob, Mark, Jerry, and others following this thread - could you also add your CC to the bug report in the QA center? https://quality.livecode.com/show_bug.cgi?id=21561 We need to get this problem squared away so that our LC code can accomplish greater things, and nothing says "it's important, it's pretty urgent" like more emails in the CC list. Anyone with more than a few lines of code is likely to benefit from this effort. Any serious code written in LCS, especially any code for working with data or calculations. Do you want your own code (and the extensions you use) to run faster or slower - if you like your code to be in shape and run a decent mile, please take a moment to join this bug report. And if anyone has sample code that hints at more (or more specific) problem areas to help pinpoint the issues, don't be shy! I believe a number of areas are affected, but who knows, maybe the root cause could be the same. Working on a WordLib update during the last few weeks has given me a good opportunity to observe the slowdown, because WordLib supports both LC 6 and 9, and it also requires thousands of tests with hundreds of documents to test fixes and ensure quality. So I measure speed too while I'm at it. Testing various code changes, I could see there are many coding tasks that LC 6 absolutely loves, even speeding up, while 9 just slows down. I ran into more potential problem areas that need to be isolated into test code once I sort them out, but may not get a chance to do so for a little while. Plus I may be missing something important. So if you have sample code that tests something I haven't, please post it. Thanks. (WordLib release will be out soon!) 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: Slow LC 9 Performance - Test Stack, Video, QA Report
That's the first thing I thought. Either everything is treated as a string until math is performed on it, or we have had a crude form of variable typing from the beginning and didn't know it. Bob S > On Sep 7, 2018, at 20:56 , Mark Wieder via use-livecode > wrote: > > 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 ___ 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: Slow LC 9 Performance - Test Stack, Video, QA Report
Mark: > if sQty = "1234567" > by your account that should be a runtime error because > it's a comparison between a number and a string? In the original Root Loops code, I assume it should be a pure comparison of i (binary, such as +5.00...) with sQty (binary, +1234567.00...) so that native math would be used and no text string involved during the loop after it gets started. But in the "big calculations" variation, the code has many numbers-as-strings that get converted each time through the loop, and that makes quite a difference on LC 9; hardly any on 6. That is definitely worth looking into. I like your "not to trust the easy answers" philosophy! Any improvements under the hood will certainly get a lot of good use. 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: Slow LC 9 Performance - Test Stack, Video, QA Report
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 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: Slow LC 9 Performance - Test Stack, Video, QA Report
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. Hm. 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 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: Slow LC 9 Performance - Test Stack, Video, QA Report
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 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: Slow LC 9 Performance - Test Stack, Video, QA Report
> On Sep 7, 2018, at 6:27 PM, Mark Wieder via use-livecode > 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 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: Slow LC 9 Performance - Test Stack, Video, QA Report
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 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: Slow LC 9 Performance - Test Stack, Video, QA Report
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 > wrote: > > Otherwise (math especially) LC6 is much faster. ___ 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: Slow LC 9 Performance - Test Stack, Video, QA Report
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 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: Slow LC 9 Performance - Test Stack, Video, QA Report
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 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: Slow LC 9 Performance - Test Stack, Video, QA Report
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 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: Slow LC 9 Performance - Test Stack, Video, QA Report
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 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: Slow LC 9 Performance - Test Stack, Video, QA Report
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 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: Slow LC 9 Performance - Test Stack, Video, QA Report
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 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: Slow LC 9 Performance - Test Stack, Video, QA Report
How did you do the JavaScript (in browser?) and how did you do the timing? ___ 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: Slow LC 9 Performance - Test Stack, Video, QA Report
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 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: Slow LC 9 Performance - Test Stack, Video, QA Report
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 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: Slow LC 9 Performance - Test Stack, Video, QA Report
totally weird! On Wed, Sep 5, 2018 at 10:03 PM Curry Kenworthy via use-livecode < use-livecode@lists.runrev.com> 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 > 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: Slow LC 9 Performance - Test Stack, Video, QA Report
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 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: Slow LC 9 Performance - Test Stack, Video, QA Report
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 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: Slow LC 9 Performance - Test Stack, Video, QA Report
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 < use-livecode@lists.runrev.com> 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 > 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
Slow LC 9 Performance - Test Stack, Video, QA Report
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 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
