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.
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.
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
-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
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,
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
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
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
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
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
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
> 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
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
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
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,
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
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
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"
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
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
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:
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,
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
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.
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
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
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.
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
28 matches
Mail list logo
