Livecode still way too slow....

[bangkok]

I for one are glad that I have a perpetual license of the last v5, v5.5.5 The IDE is much faster than later revisions, resulting apps too. And smaller.

Same here : i keep using 5.5.3. Over and over again. Should I feel ashamed ?

Windows 8, Windows 10 even on super hardware... Livecode 8.x is slow. The IDE is slow.

I mean there is no test to do, or benchmarking to analyse : it's obvious...

So the good old 5.5.3 is still okay.

I use 8.x only for specific projects, when I have to rely on TSNET (a great improvement, for better/stronger networking) and of course for Android.

[dunbarx]

Ahem.

I am way, way ahead of you guys. I languish in 6.7.

Craig Newman

[atmosk]

CHECK viewtopic.php?f=6&t=28591&p=173812#p173812 FOR UPDATED/IMPROVED DATA

Sorry for the necro, but the "slowness" issue popped up for me again (this was also the #1 google result so felt this could be the place to post the following).

Since FourthWorld ran his test in 6.7 as opposed to the 6.5 mentioned by the OP. It felt a bit questionable whether the results were reliable so, I installed every stable version from 6.0.1 (not incl. in the end since it required license) to 9.0.1 and ran a slightly modified version of the test by FourthWorld +4 times in each version to see what gives.

Some things to mention:
All were community edition. Ran the tests in the IDE, didn't compile and on windows 7.
6.0.2 to 6.1.3 seemed to hang resulting in +10 sec times on the lines test and incorrect(?) icon times too (check edit).
6.6 crashed consistently, no datas.
7.0.4 didn't accept the "0,0,50,50" point list so replaced with "0,0" & cr & "500,500".
8.1.8 and 8.1.2 did what looks like "lock screen" randomly on their own.

Results:
The icon test was on average between 242 to 310 ticks on all versions (except on 6.0.2 to 6.1.3) so not a lot of funky going on there.

The points/line test on the other hand looked a lot different.
From 6.5.0 to 6.6.1 the average was between 0.33 to 0.44 sec.
Then from 6.6.2 all the way to 8.1.10, the averages were between 1.14 to 1.23 sec (with the exception of 8.1.8, 8.1.2 and 6.7.11 which were 0.95/0.53/1.06 respectively).
Followed by 9.0.0 and 9.0.1 which were again 0.37 and 0.37.

So it seems like he was at least partially right.

Couldn't attach the .livecode file so here is the file uploaded to uploadfiles.io: https://ufile.io/qee50
Here's just the datas https://pastebin.com/Wi8pLeXS

Since I already installed all the versions I'd be up to running a more thorough "benchmarking" test to see what things have changed between the versions, but unfortunately my knowledge isn't good enough to really know what to even test in what way that the results would be even somewhat meaningful so if someone writes a test stack I'd be up to running it. Got the automation set up anyway so would be wasteful to not use it?

(There is also the single times of each measured action, but I figured I'd keep with the way the times were being reported on this thread.)


Edit: After some further thinking, I realized the icon tests ran very fast in 6.0.2 to 6.1.3, but the line/points part hung. So I redid the only icons tests and here is the data from those and as a sanity check, redid 6.5 and 6.5.1 too, https://pastebin.com/3nqhL9GM
A whopping difference of 200 ticks.

[bogs]

I don't think it is too 'necro', and I think it is great that you ran the tests and posted such detailed results

I also don't think it is any surprise to almost anyone that, especially when working in the IDE, you'd find certain things to be slower. Some of the slowness is so obvious you can tell without any performance counters. Brian and I had some fun with fields and html text a while back, the newer field with exactly the same code was *painfully* slower than the older version.

Aside from speed, there have been new errors ceeping into fields as well as Craig pointed out with the table field, although that started back in 7 (I think, maybe it was 6.7.x ).

You could modify Richard's tests to cover almost any control, changing the script to test common uses by type. The question is whether you'd gain anything (other than more specific knowledge) by doing so.

[atmosk]

It's adequately necro for the necro minded and I've learned better than to taunt them

If you consider the posts in this thread, then the impression you'd (I did) get is that tjframe is semi-delusional and/or it's the fault of his hardware and there is no significant performance dips between versions (ignoring the last 3 posts before mine which didn't contribute other than with "anecdotal evidence" (not to dismiss, but it does weigh less than numbers when you scan through topic after another to find a solution)).

Which if my tests were reliable, then isn't the case and he was right (partially).

Then again would be wrong to go down the path of "LC just keeps getting slower" as well, since at least the point swapping reached it's former top speeds in 9.0 and 9.0.1 again.
Which in my case meant that I'll be migrating my current project to 9.0 since 9.0.1 had other "issues", from 8.0 (dp7).

Anyway that leaves the IDE issue in the air still, so I went ahead and made standalone stack launchers from each version and it seems to follow along the IDE times (almost) to the t. To my surprise, there was very little benefits from the standalone other than significantly less hanging and freezing. I'd always imagined it was an order of magnitude difference

Data from that: https://pastebin.com/fWR3kN35

As for the benefits of doing this, maybe someone at some point will need this information and they'll be a little less headached. E.g., if their entire project involved only swapping icons at an excessively high rate, they'd be best off with LC version 6.0.2 to 6.1.3.
As for me, I put the stack launchers and installations on an extra hdd so it'll be there if someone comes up with good tests

[FourthWorld]

@atmosk: did you add the recommended "lock screen" to the rendering test? Some compositing routines are more sophisticated in versions after 6.x, but in my tests were reasonably well offset by avoiding unnecessary redraws that wouldn't normally be part of production code.

@bogs: which field bugs were introduced in v9? I rely heavily on fields and would like to help triage any bugs remaining in 9.0.2.

[dunbarx]

Also don't agree with the LCB path taken. I think LC script itself should be improved to handle that task as well instead of creating a new language (without IDE too...).

That is a point I have been musing about. I do not use LCB.

@Richard. Can you give a brief summary of the benefit/momentum/excitement/ROI of the LCB world? Is it attracting new users that might not otherwise consider LC? Is it enabling existing LC users mightily?

There is relatively little activity in the LCB pane.

Craig

[FourthWorld]

Also don't agree with the LCB path taken. I think LC script itself should be improved to handle that task as well instead of creating a new language (without IDE too...).

That is a point I have been musing about. I do not use LCB.

@Richard. Can you give a brief summary of the benefit/momentum/excitement/ROI of the LCB world? Is it attracting new users that might not otherwise consider LC? Is it enabling existing LC users mightily?

For the work I'm doing at the moment LC Script has been more than sufficient; I haven't yet encountered a need for LC Builder myself.

But the ability to directly access OS APIs from a friendly scripting language sure blows the pants off of having to use C with the older externals interface, and a lot of people seem to like it.

[dunbarx]

Good to hear.

I so want LC to take over the world.

Craig

[richmond62]

I so want LC to take over the world.

Not a very good idea as monopolies go mouldy after a while.

But I do want LiveCode to take what I believe is its rightful place in
the top 10 programming environments, and the top banana in school.

[bogs]

@bogs: which field bugs were introduced in v9?

Hm, I'm pretty sure I said -

Aside from speed, there have been new errors ceeping into fields as well as Craig pointed out with the table field, although that started back in 7 (I think, maybe it was 6.7.x ).

Although it was reported in the bug db when it was initially discovered (I still think it was in 7.x), apparently almost no one knew about it or remembered it till Craig pointed out the random table cell issue more recently, a thread a lot of people showed interest in. In any case, it isn't new to 9.x, recently is when it was 'rediscovered'.

Probably my poor choice of wording is again at fault, for that my apologies

Anyway that leaves the IDE issue in the air still, so I went ahead and made standalone stack launchers from each version and it seems to follow along the IDE times (almost) to the t. To my surprise, there was very little benefits from the standalone other than significantly less hanging and freezing.

Perception of speed matters when someone is using the toys you make, so even though a developer might choose to suffer with having the IDE drag down to a crawl when they, say, open the project browser with 6 tabs in the script editor using autocomplete (which shouldn't happen, btw ), that dev is going to have a much harder sell with someone who tries the software and it oh, pauses for a noticeable time period.

So I would say that there is a very GREAT benefit in the standalone test, even if all you proved is that some one using something you programmed won't have the same agonies as you experienced writing it

I tend to agree with the quote in Craig's post (made while I was typing this one), I also don't tend to think the LCB is going to be a big strong point for people who pick up Lc for the xtalk. I have no doubts whatsoever that there *are* people who will make great use of it, such as -hh, but even he got frustrated with the changing format at one time, and it is questionable to me whether or not all these great 'widgets' couldn't have just been templated like any of the other controls included as standard.

I know this part of Craig's post was to Richard -

Is it enabling existing LC users mightily?

but I can't see it doing that for the average Lc user. Power users like -hh maybe, as his thread with the bazillion widgets is testimony too, but speaking for myself, I don't find much interest in them.

[richmond62]

Why do I feel that the table field is an orphaned feature which got abandoned
when someone cooked up the dataGrid?

I believe it is a great shame that the table field is not what it could be as
it is far easier to cope with than the dataGrid while offering a lot of useful features.

Livecode still way too slow....

This is one of those nebulous headings that serve no real purpose.

The question is "Livecode still way too slow...." for What?

And the What needs to be specified as Livecode is not slow for everything.

[bogs]

Why do I feel that the table field is an orphaned feature which got abandoned
when someone cooked up the dataGrid?

You did download Bernd's tablefield tricks stack, right? Cause that is pure awesome

The question is "Livecode still way too slow...." for What?

Well, I don't delve into graphics nearly as much as the OP, so *my* feeling would be more like "The Livecode IDE is still way too slow...." for What? for developing programs in

However, Xojo's IDE (last time I used it anyway), was far FAR slower. Having said that, I don't think Lc should race Xojo to the complete stop department in IDE speed

[FourthWorld]

A table field is a LC-native field with its grid properties set. It has not been abandoned. I use it daily.

[richmond62]

I use it daily.

Wow! Some of my best friends are table fields.