LiveCode Forums.

[-hh] wrote:Hi Thierry,

just looking for a way out of this, I see your nasty problem:

If I need frequently answer file/ask file/save/open then I use
"set systemfileselector to false"

Vielen Dank Hermann, but it's not an option in my case

Kind regards,

Thierry

Hi Thierry,

Thierry wrote:... and the delay I and few others are experimenting is around 20 seconds !

Not only few others, presumably each and every Mac user of LC has a delay of 10-20 seconds, I really wonder why only four users wrote to that here. I think, the dev team doesn't know how to salvage this. I'll bet they have this delay on their Macs too.
And the folks from Apple also don't know how to salvage this and have this delay on their machines for some apps (LC is not the only one according to Mac forums). Is the problem too deep connected with old/Carbon MacOS parts?

Hermann

Thanks Hermann for the bug report.

I added some extra information...

http://quality.livecode.com/show_bug.cgi?id=16612

Thierry

I see the same behavior on MacOSX 10.9.5 Mavericks: the first time after LC is opened it takes about 20 seconds to open a "save" or "save as" commond. After that "save" etc. work fast.

I remember Trevor Devore saying that he observed the same behavior on one of his Macs, while the others work just fine. So it seems to be a bit more complicated to track this bug down. There obviously are configurations that show the slowdown while others do not, just as Panos can not reproduce the slowdown on his Mac.

Kind regards

Bernd

Do all of you who have this delay have an external usb hard drive? (mechanical, not just a thumb drive) IF so, I wonder if it is in power save mode, and the system hangs while it is spinning up.

sturgis wrote:Do all of you who have this delay have an external usb hard drive? (mechanical, not just a thumb drive) IF so, I wonder if it is in power save mode, and the system hangs while it is spinning up.

No and this happens *only* with Livecode; all other apps behave well !

Regards,

Thierry

Ok, it was a thought. If I think of anything else I'll post it here.

On Linux I've been able to use strace to identify bottlenecks; I wonder if using the OS X equivalent, dtrace, may be as fruitful:
https://blog.8thlight.com/colin-jones/2 ... r-osx.html

FourthWorld wrote:On Linux I've been able to use strace to identify bottlenecks

You can check QCC where I did put some trace; but then I'm in lost:

http://quality.livecode.com/show_bug.cgi?id=16612

I have been experiencing similar problems. During execution, a stack will sometimes become completely unresponsive, and not just the stack, but the whole Mac OS. This occurs on both an MacBook Air and an iMac under the latest OS X (but also occurred under previous OS X versions) and under LiveCode 8.1.3*, LiveCode 8.1.1*, LiveCode 8.0.2 and LiveCode 7.1.4 and probably under some earlier versions, too).

The only solution is to shut down the machine in use with the power switch, as Force Quit cannot be summoned: the Finder is simply unresponsive, the Dock fails to appear, there is no response at all.

After some testing, I believe there is a connection with the use of sounds in the stack. I have modified the stack to run without the sound elements (one or no sound-clip included on each card); the limited OpenCard script has been eliminated; there is no CloseCard script; the simple script used in the test is no more than a go to next cd for all cards. While the LiveCode script was running, the Activity Monitor was active.

- with the sound-clip eliminated from all cards, the same simple script shows a Threads count starting at 5 and ending at 7;
- with the sound-clip included, the Activity Monitorshows an ever-increasing number of Threads, with the Threads count in this case starts at 10 and ends at 894.

LiveCode was started afresh for each test.

I have posted videos of this at http://davidneale.eu/livecode/threads-i ... sound.html

The tests were performed with LiveCode 8.0.2.

*Re LiveCode 8.1.1 and 8.1.3, it is not even possible to run the simple script under 8.1.1 and 8.1.3 with the "sounded" stack: everything halts after some 500 (it varies from test to test with the same data) Threads are reached, when a card stops for several seconds, then goes to the next one, then the Activity Monitor shows "LiveCode not responding (in red). With the "soundless" stack, everything works fine (at least as far as this test is concerned), with Threads starting at 5 and ending at 7.

Hi David,

I do not have a Mac to test this sound file bug, but opening 894 threads to play a sound file is clearly excessive.
Check this bug report and tell us if any of proposed solutions works in your computer:
http://quality.livecode.com/show_bug.cgi?id=16612

Al

None of the proposed solutions helped, so I removed the player from each card on which it was present. LiveCode 8.1.1 now goes through the stack correctly, with the Threads count not exceeding 10 and without unexpected freezes.

Checking the stack, it is noticeable that 439 of the 506 cards contained a player object. It looks suspiciously as if each player object generates two threads, which then remain active. The Mac freezes before LiveCode reads all of the cards, so perhaps when memory becomes in some way overloaded (preumably, but I am not technically proficient here).

So, is there a way in LiveCode to stop/clear the threads started by player objects?

Hi all,

The "multiple threads issue with multiple cards contains players" is this bug http://quality.livecode.com/show_bug.cgi?id=19693, which will be fixed in LiveCode 8.1.5 RC-1. The problem was caused because some system resources (those related to the player instantiated for each card) were not freed until the card/stack is deleted from memory, instead of being freed when a card closes.

Best,
Panos
--