Very slow stepping thro code (7000 lines)

[kaveh1000]

Thank you very much Sphere. But pls note the problem is having one big script that is causing the problem. If I were to split the script amongst buttons, cards, etc. it would be fast to edit and to debug.

[dunbarx]

Kaveh.

I made a script of 8000 lines. I do see a slowdown, not nearly of one second though, when, say, creating a new line after pressing return.

More like 1/4 second, just enough to notice the difference. I suspect this is not "fixable" unless you do indeed break that script at least in half or so.

This is also a "feature" of LiveCode in managing large numbers of cards. Unlike HC, which did not seem to care, LC slows down significantly if a stack contains more than about 2000 cards. To me, that is far more uncomfortable, since it may well be desirable to have a large stack. The solution, to offload data to an external file, works fine, but flies in the face of the "standard" thinking, at least my standard thinking, of what a stack ought to be.

Craig

[kaveh1000]

Hi Craig

Thanks for doing this. I also see something like 1/4 sec when typing, which is bad in itself. But the main drawback is stepping thro code (normally step Over) which is taking around 4 seconds. That is the main issue. I will see if I can split the code...

Kaveh

[sphere]

just for some info, so indeed when one starts to count lines and handlers, then maybe you'd be surprised how many you've already written.

I've counted a bit of my biggest project: it uses 7 apps (mobile and desktop) of which the biggest has indeed up to 7500 lines but spread over 104 scripts/buttons/datagrids(which means dg scripts where for the most part already there) and +/- 25 handlers or less for each app. Also this project uses +75 PHP files to communicate to the DB with 10 up to 30 lines of code.

So perhaps (just thinking) the engine is faster when code is spread in multiple places, instead of searching a handler in a very large single script, it might be faster to look in a certain button or card to find the code you need there(dispatch/send). But i can also understand for your own overview where to find your stuff more easy.

[brotee]

With LC 5.x it was worked, i had over 10 000 lines without any problem. But now it's the same for me, it was almost impossible to do anything .. about 1 second every keypress, and debug was impossible too . So we decided to gave up mobil support and we are working with WPF and only Windows. I think LC is good for small and simple apps, nothing else, but even a small app is way faster on android if u use native language.

[FourthWorld]

I'm having trouble reproducing this - even when working on a script with 15,000 lines.

Here's the test I ran on Mac, Windows, and Linux, using the latest build, LC 9.6dp2:

- Copied the script of stack revLibURL.
- Pasted into the card script of a new stack.

That script is only about 5k lines long, so:
- Pasted it two more times - total lines > 15,000
- Removed a few duplicated local declarations as needed for compilation.

Then I edited: added returns, deleted some text, typed a bit, etc.

Note that my Windows test was the most restricted: it was on a VM running on a very modest host, under tight memory conditions, while Windows Real Time Protection was turned on, while the Windows updater was running. Kinda the worst of all worlds, yet any delay in responsiveness to keyboard activity was a fraction of a second at most.

So...

The next step is to figure out how to reproduce the issue reliably on other machines. Once we can do that we can begin to hone down the bottlenecks.

One that that would help diagnostics a lot:

For those of you seeing significant delays in Script Editor performance, how does SE performance compare to:
- ...pasting into a new field and editing there?
- ...pasting into Wordpad and editing there?

[mrcoollion]

I have had a very slow saving problem and slow stepping thro code (LC 9.5.1. and 9.6 dp1 and dp2).
I accidentally discovered that the cause of the problem was 'probably' a massive amount of data in a field on another card and maybe having some array's that were unnecessary filled with a lot of data.
After emptying the field, saving became a lot faster and stepping thro also somewhat better.

It could be that the amount of memory usable in Windows 10 is limited to 2GB because LC is not yet an actual 64bits application?
See 9.5.1 Release notes: Note: On 64-bit Windows installations, LiveCode runs as a 32-bit application through the WoW layer.

On Windows, under normal circumstances a 32 bit process can only access 2GB of RAM (or 3GB with a special switch in the boot.ini file). When running a 32 bit process on a 64 bit operating system the app can only access 2 GB by default. If the application is large address space aware (linked with /LARGEADDRESSAWARE), it gets 4 GB (not 3 GB, see http://msdn.microsoft.com/en-us/library/aa366778.aspx).

So LC is probably still limited to 2 GB since many applications depend on the top bit of pointers to be zero.

Some more info on the Windows WOW64 layer if you are interested.
https://docs.microsoft.com/nl-be/window ... onsumption

Just an idea...

Regards,

Paul

[FourthWorld]

2 GB is a lot of memory for a single application. What exactly do you have in that field?

[bogs]

Just out of curiosity Paul, what kind of data are you dealing with? Is it all text? Or are you mixing text and graphics? Along those lines, what size are the stacks your working with? And have you checked to see how much memory your actually dealing with through the task manager?

To put some perspective on the questions, here is a table of different kinds of data, and the average amount that would be required per GB -

HOKEY SMOKES!! 1.21 GIGAWATTS...!

- So if your working with plain text files, I'd find it pretty incredible if you could even come close to the theoretical limit of 2 gigs. Images might take up more space, but that would still be a lot of images.

LOL, I see Richard was thinking along the same lines

[kaveh1000]

Thanks for your comments everyone. If I can just butt in here, I am dealing only with text. My stack is to manipulate text in 2-3 fields. Only one card, and no images.

I am using a script only stack with 7000 lines of code. It is hard for me to test Richard's suggestion of putting all the code in the script of a field, as the stack would not work.

When I edit the file in a text editor, e.g. BBEdit, it is fast as I would expect it to be.

To emphasize, altough the editing is a bit slow, the main problem i have is the slow speed of stepping into or over script lines.

[FourthWorld]

I am using a script only stack with 7000 lines of code. It is hard for me to test Richard's suggestion of putting all the code in the script of a field, as the stack would not work.

It doesn't need to run. The purpose of the test is to try to isolate the cause of the editing lags.

All we're looking for is to see if an LC field object allows satisfyingly performant editing on your system. If it does, we can rule out the engine half of the equation and focus on the scripts that comprise the Script Editor.

To emphasize, although the editing is a bit slow, the main problem i have is the slow speed of stepping into or over script lines.

Way back in the olden days, long before LC was born, MetaCard's Script Editor and Debugger were two different stacks. This separation of concerns allowed a leaner design, both in UX and in underlying code.

I have no idea why the very different tasks editing and debugging were conflated into a single window, and that design decision may only marginally contribute to the performance issue. But with all the layers of hiding/showing parts and pieces of one thing or another, no doubt the conflation of those two inherently different tasks into a single window at least contributes to the difficulty in updating it when stepping through code.

[kaveh1000]

OK. I pasted around 7000 lines into a field in a very lean stack. Pls see screen recording:

https://drive.google.com/file/d/1DdpJ8i ... sp=sharing

I typed very fast and finished typing before the first line all appeared on screen. After that the engine is catching up.

[FourthWorld]

That video shows what looks like the script editor. The goal of this test is to assess editing performance in an unadulterated LC field object.

Do you see a difference between editing in a field and editing in the SE?

[kaveh1000]

Oops, sorry, my error.

I have pasted in a field text now, and editing is absolutely fine, with no lag.

[FourthWorld]

Thanks.

Do you have any plugins installed other than the ones included my default? If so, what are they?