CPU usgae

Deploying to Mac OS? Ask Mac OS specific questions here.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

dalkin
Posts: 176
Joined: Wed Jul 04, 2007 2:32 am
Location: Blackheath, Australia
Contact:

CPU usgae

Post by dalkin » Mon Jul 12, 2021 4:07 am

I have just upgraded to LC 9.6.3 (rc1) on the following system
Screen Shot 2021-07-12 at 12.18.04 pm.png
but when I open a project and run it, the CPU goes nuts and everything slows to a crawl.
Screen Shot 2021-07-12 at 12.12.30 pm.png
This seems to be an ongoing issue (LC+BigSur) .. unfortunately, development slows to a crawl but I don't know whether it's a bug in my stack files or a bug in LC. Any suggestions? I'm happy to make the project file available to anyone who wants to test it locally.
If we're treading on thin ice, well you might as well dance.

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 9287
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: CPU usgae

Post by richmond62 » Mon Jul 12, 2021 6:40 am

MacOS 11 and LiveCode do NOT sit well together at all.

Having upgraded to MacOS 12 beta 2 everything seems to be as it should.

dalkin
Posts: 176
Joined: Wed Jul 04, 2007 2:32 am
Location: Blackheath, Australia
Contact:

Re: CPU usgae

Post by dalkin » Tue Jul 13, 2021 2:19 am

Thanks. I suspected it was something of a terminally ill nature. I guess that means that any 'for sale' Mac apps should be labelled with a "do not use on MacOS Big Sur". The compiled app I have developed runs like a dog.
If we're treading on thin ice, well you might as well dance.

Bernard
Posts: 351
Joined: Sat Apr 08, 2006 10:14 pm
Location: London, England

Re: CPU usgae

Post by Bernard » Thu Jul 22, 2021 6:56 pm

This is not the case on Big Sur/M1.

LC is generally running at 2% to 9% of CPU. The only time I saw it go as high as 30% was when I was searching through all the scripts that make up the development environment.

dalkin
Posts: 176
Joined: Wed Jul 04, 2007 2:32 am
Location: Blackheath, Australia
Contact:

Re: CPU usgae

Post by dalkin » Fri Oct 01, 2021 1:05 am

I'm back on the prowl for solutions to issues with OSX Big Sur and LC. I have recently upgraded to LC 9.6.5 RC1 and the crashing, freezing I have experienced on earlier LC versions persists. Here's a screenshot of the Activity Monitor running at 99.5% .. oh, and did I mention that I had to force quit LC BEFORE I took a snapshot of the CPU resources.

Image

and here's a screenshot of another annoying feature, LC appearing twice and sometimes three times in the OSX Dock

Image

I have previously lodged a bug report where the solution was to avoid using LC Default Buttons with a bit of code on the preOpen card handler:

Code: Select all

on openCard
   lock screen
   repeat with i = 1 to the number of buttons
      set the default of button 1 to false
   end repeat
   unlock screen
end openCard
which is super weird in itself. The problem remains that any app for OSX that I create continues to run like a spotted dog to the point where I will have to remove the OSX version of the app from its website as it's unfit for purpose because of poor memory handling. Can anyone point to a release date for LC10? I also note that the support staff are using OSX Catalina, so the Big Sur issues must have been identified but are not able to be fixed.
Attachments
Screen Shot 2021-10-01 at 9.50.48 am.png
Screen Shot 2021-10-01 at 9.11.31 am.png
If we're treading on thin ice, well you might as well dance.

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: CPU usgae

Post by LCMark » Fri Oct 01, 2021 6:52 am

@dalkin:

As I explained in my response to your bug report, with the version of the stack you supplied, all CPU related issues were fixed when running on Big Sur by ensuring no default buttons were used. (Indeed, even on Catalina your stack was using more CPU on the card after 'Login' than it should - for much the same reason).

The small loop I provided was a simple way to ensure there were none on any particular card - however it would be better if you went through your UI and turned 'default' off for all buttons (perhaps style them in a different way?) and then save that into the stack so they are never appear like that in the first place.

Default buttons have one very specific purpose - to mark which button on a dialog is the 'default action' (indeed, in that context on some platforms they are also tied to the return key to enable fast dismissal) - this means that with proper use there would only be one, and even then only one in a transient (dialog/modal) window.

The reason default buttons currently cause such a problem is that they are potentially animated and thus cause repeated screen redraws - if you have 8 of them on the card (which I think is the case on the 'Lyricist' card) then that means the engine is repeated redrawing 8 areas of the card separately. Screen redraws (due to a breaking change in an underlying OS API call we used to use on macOS) are a lot slower on Big Sur than prior macOS versions - hence this multiple (unsynced) animation causes a big issue.

There is an engine issue here, certainly, namely that I don't think default buttons any longer do have an animation on at least Catalina and Big Sur (we need to check this more deeply) - so on those OS versions we can skip the redraws. However, I'd still advise people not to use default buttons except in the circumstance they are designed for - i.e. as the default action button in a modal dialog.

SparkOut
Posts: 2839
Joined: Sun Sep 23, 2007 4:58 pm

Re: CPU usgae

Post by SparkOut » Fri Oct 01, 2021 7:28 am

If this wasn't a typo, your script to deselect the default of the buttons always refers to button 1, not button i (the index value of the loop) so that might be why you didn't find this to be a fix.

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: CPU usgae

Post by LCMark » Fri Oct 01, 2021 7:43 am

@SparkOut: Oh good spot!

That was my fault - when I was investigating the bug report I must have copied the wrong version of the loop from the message box history (I was prodding the stack in various ways)...

Apologies @dalkin - the loop I should have advised to use to turn off default for all buttons on a card should have been:

Code: Select all

   repeat with tIndex = 1 to the number of buttons
      set the default of button tIndex to false
   end repeat

stam
Posts: 2634
Joined: Sun Jun 04, 2006 9:39 pm
Location: London, UK

Re: CPU usgae

Post by stam » Fri Oct 01, 2021 7:50 am

Not to sound anachronistic or like a broken clock, but have u tried using 9.6.2 RC2?

That version fixed most of the Big Sur issues and had excellent performance.

In an attempt to fix some other issue, from 9.6.2 RC 3 onwards and every subsequent major version, performance has taken a big hit, especially when manipulating graphics. What used to be instantaneous now happens slowly enough for the eye to easily perceive the gradual changes in graphics. Not a showstopper but bad enough to force me to keep a version of 9.6.2 RC2 on my system to actually produce standalones that behave as apps and not scripts.

Since LC have removed all previous RCs not sure how you can get a copy of this (foolishly I deleted the installer as I thought we’d have access to these on an ongoing basis - I thought we were now past the point of herding installers on local storage, more fool me), but perhaps someone here has it or maybe LC would be willing to share.

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: CPU usgae

Post by LCMark » Fri Oct 01, 2021 8:19 am

@stam:

9.6.2 RC2 fixed a number of Big Sur issues but still contained problems with window redraws - basically causing stacks in various circumstances to not redraw correctly, causing tearing, partial updates - basically a bit of a mess) - this was fixed in 9.6.2 RC3 however it does mean that there is a performance impact on stacks which update the screen repeatedly without using lock screen...
e.g.

This (entirely synthetic) code:

Code: Select all

set the backColor of button 2 to blue
set the rect of button 2 to the rect of button 1
set the text of field 1 to "Hello World!"
Will run much slower than doing:

Code: Select all

lock screen
set the backColor of button 2 to blue
set the rect of button 2 to the rect of button 1
set the text of field 1 to "Hello World!"
unlock screen
The current redraw model of LC is that the engine will force a window redraw after each command which may have changed how something looked *unless* inside lock screen in which case the redraw is deferred until unlock screen (well, except when you do a 'wait' - the engine cannot stop the OS updating the screen when events are being handled!).

For whatever reason, the OS API we used to force a partial area of a window to be redrawn does not work correctly in Big Sur - we don't know why - so we have to force a screen redraw in a different way hence it now being significantly slower.

To be fair, not using lock/unlock screen appropriately has always caused things to run much slower than is necessary (as screen redraws are expensive regardless) - its just that on Big Sur this fact is completely obvious now.

Rather than relying on using an unsupported version of LC, I'd advise updating scripts to use lock/unlock screen around code which sequentially updates objects - this might be a bit of a pain, but your code will actually run better / faster on all platforms (and will also resolve any issues on Big Sur).

I should perhaps note that macOS/Android/iOS really don't like apps asking for immediate window redraws at all - they much prefer it if you let the windows be redrawn at the point events are handled (hence why if you do a wait in a lock screen, windows get redrawn whether you like it or not).

The problem is that the current redraw/update model is what LC has pretty much always had (admittedly, I refined it 15 years ago to make it entirely consistent and reliable - but the prior intent was always clear) and this is very much 'at odds' with how 'modern' OSes want to do things.

That being said, I am pondering whether 'now' (as in maybe 10) may be the time to drop the current model from 'update after every command if needed' to, 'only update when explicitly asked for' - i.e. make it so code essentially always runs under 'lock screen', but add a 'refresh screen' (or similar command) which forces a screen redraw (with the understanding that this will be slower).

stam
Posts: 2634
Joined: Sun Jun 04, 2006 9:39 pm
Location: London, UK

Re: CPU usgae

Post by stam » Fri Oct 01, 2021 8:32 am

Thanks @LCMark - I do use Lock Screen very liberally and it does help significantly (this was more based on trial and error some time ago rather than official advice, and thank you for explaining why this actually is), but I find that even so, performance isn’t quite as good as 9.6.2 RC2, so I don’t think that’s the only issue.

Might be unsupported, but I keep a copy of 9.6.2 RC2 around along with the current official version, mainly to provide a benchmark for my code - if something is running slow in RC2, it’s my code’s fault and not liveCode’s ;)

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: CPU usgae

Post by LCMark » Fri Oct 01, 2021 8:38 am

@stam: The only thing that would cause a performance difference between (the same) code running in 9.6.2RC2 and later versions will be the screen redraw issue outlined above - so if you have a specific case which you can distill down to simple stack showing it then please do file it as a bug in BZ so we can take a look.

Bernard
Posts: 351
Joined: Sat Apr 08, 2006 10:14 pm
Location: London, England

Re: CPU usgae

Post by Bernard » Fri Oct 01, 2021 10:00 am

LCMark wrote:
Fri Oct 01, 2021 6:52 am
However, I'd still advise people not to use default buttons except in the circumstance they are designed for - i.e. as the default action button in a modal dialog.
I'd noticed probably a decade ago that just having a single "default button" on a card would cause CPU to jump to 10% or so every time the button throbbed. Consequently I have rarely used them.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: CPU usgae

Post by FourthWorld » Fri Oct 01, 2021 3:23 pm

Bernard wrote:
Fri Oct 01, 2021 10:00 am
LCMark wrote:
Fri Oct 01, 2021 6:52 am
However, I'd still advise people not to use default buttons except in the circumstance they are designed for - i.e. as the default action button in a modal dialog.
I'd noticed probably a decade ago that just having a single "default button" on a card would cause CPU to jump to 10% or so every time the button throbbed. Consequently I have rarely used them.
It's better now that Apple stopped having the only OS that eats CPU cycles pulsing a default button. Back when they were doing that you could see a noticeable bump in CPU load even in Apple dialogs.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

Klaus
Posts: 13806
Joined: Sat Apr 08, 2006 8:41 am
Location: Germany
Contact:

Re: CPU usgae

Post by Klaus » Fri Oct 01, 2021 3:36 pm

Yeah, I remember a customer who sent me his (Mac) stack "Please take a look, it does not do anything anymore" a couple of years ago. And I found about 20 nicely blue throbbing default buttons on the first card, which grinded the stack to a standstill! :D

Post Reply

Return to “Mac OS”