Absurd CPU Usage!

[rrBUSS9EE]

Hey all,

I guess this is more of a heads up than anything else. In another topic, a very nice fellow pointed me to a stack as an example for something I was looking to do. When looking through this stack I noticed some unreasonably heavy CPU usage, and wanted to track it down to try to reduce it.

I looked everywhere and found nothing that explained the load, yet when I closed the stack, LC returned to normal. Reopen the stack, bingo 18-20% of a 2.4Ghz i5 seemingly for nothing. No idle handlers, just nothing I could find. A real head-scratcher.

After quite the easter egg hunt, I finally discovered what it was. It seems the developer made a critical mistake. He put a "default" button on the main card of his stack. Don't put a default button in a permanently displayed area of your interface.

[Mark]

Hi,

Consider this a good lesson. It is bad GUI design to put a default button anywhere but in a dialog window. It is even worse to put multiple default buttons on a window. Many people do this. Don't.

On the other hand... I agree that it is absurd for one single button to require that much CPU power.

Kind regards,

Mark

[FourthWorld]

Exercise for the reader:

1. Open Apple's System Monitor
2. Open Apple's TextEdit
3. Type some random text
4. Note the CPU usage in System Monitor (here it's almost zero)
5. Click the close box
6. While the save prompt dialog is up with its pulsing default button, check the CPU usage
RESULT: here it's about 8.5%

At that point Apple's TextEdit is effectively idle, yet it's consuming 8.5% of CPU power. How is that?

Take a good look at the default button, and imagine the many steps that need to be done to render that. Any animation will consume far more CPU cycles than a static image, and here we see that even the best effort from Apple's engineers eats clock cycles like ice cream, which helps us appreciate why other OSes distinguish default buttons with a static appearance.

When you repeat that same test with LiveCode, you'll find that it uses almost twice as many CPU cycles as the fully-native routines in Cocoa, but this is understandable given the way LiveCode works.

In Cocoa (at least the last time I explored this in detail a couple years ago), the default button rendering is provided only against the OS-native background. In earlier versions of OS X this was the seersucker pinstriping, and in more recent versions a shade of gray. According to Apple engineers, attempting to render a default button against anything other than the default background will cause the edges to be antialiased as though you're using the default background. So for example, if you've placed a default button over an image, the edges of the button will not reflect that and instead have traces of the default background that's not actually beneath the button.

This limitation is perfectly fine for most conventional apps, since of course the HIG suggests using default buttons only in specific contexts which should always have the default background beneath them.

But LiveCode developers are accustomed to having the freedom to put any controls over anything else however they like, and to have the same layout rendered with equal fidelity on Windows and Linux as well. The LiveCode engine's rendering scheme supports this robustly, but at a cost to CPU cycles.

LiveCode calls OS routines to draw much of most standard controls, but then augments that drawing to use its internal text engine to render the label (allowing us to work with text consistently and flexibly across platforms), and then uses its own compositing to render the control on the card with the other controls (allowing any layout you can imagine). For static elements this only happens once when a card is opened, so the overhead needed to accomplish this is largely imperceptible. Indeed, LC has a reputation for being unusually fast in most respects for what it provides.

Since LiveCode has uncommon needs in terms of the scope of flexibility its users expect from it, it uses uncommon methods to render controls, and that additional work will require more CPU cycles when accommodating OS X's unique animated default button.

In the most recent version, you'll find that rendering OS X's pulsing default buttons takes roughly twice as much CPU power as the OS-native implementation in Cocoa. While this may seem high compared to native Cocoa apps, those Cocoa apps won't run on Windows and Linux, and even on OS X they won't render properly against anything other than the default background.

Moreover, as Mark noted, default buttons are best used sparingly anyway, usually limited to dialogs that are present only momentarily. Since those dialogs are waiting for user input, the additional CPU overhead should pose no impairment of performance for any business-logic processing your app needs to do later. Even at ~17% this will not likely have any perceivable impact on the performance of other apps during the brief period in which your LiveCode dialog is up, no more than Apple's native rendering consuming unusual CPU cycles has been a problem for Cocoa devs.

[rrBUSS9EE]

In the most recent version, you'll find that rendering OS X's pulsing default buttons takes roughly twice as much CPU power as the OS-native implementation in Cocoa.

My testing here shows about three times that of the native control. Hard to believe that can't be optimized a little better.

[Mark]

Hi,

As I indicated before, I agree that the default button needs to be optimized. I have been of this opinion for about a decade now, but I don't expect it to change.

Kind regards,

Mark

[FourthWorld]

If it's hard to believe, you may not have written a multi-platform rendering system before. Give it a shot and you'll see what I mean. I tried and gave up many years ago, preferring the ease of letting RunRev do 90% of my work for me instead.

The exact percentage of difference between Apple's own high CPU usage for their unusual default buttons and LiveCode's handling of that control will vary from system to system, also likely affected by the specifics of the layout (number of other controls, overlap of those controls with the default button, use of accelerated rendering options, etc.).

LiveCode's rendering of OS X's unique animated default button has already gone through one optimization several years ago, dropping its CPU usage by a significant percentage.

No doubt there's still room for further optimization, and it might be helpful if the RQCC # were noted here for those interested in raising the visibility of this issue.

It may be that their current work on accelerated rendering could lend itself to a cost-effective way to further optimize the rendering of this one control on the one OS that uses it. But if it requires much work specific to it there are enough other enhancement requests that directly affect end users on the other 90% of computers, and many more that affect users on all platforms, that we may have to be patient on this one.

For the reasons Mark noted earlier, when used in a HIG-compliant manner it's not the sort of thing end-users complain about, if they notice it at all.

Having shipped dozens of commercial products since I first started using this engine in '97, including very favorable coverage in a number of Mac-specific magazines, the only CPU-related complaint I've ever had from any end-user was related to a timer I had with a frequency that was too short. That was all me, not the engine, and simply increasing the interval between calls fixed it in one line.

Use default buttons as the HIG suggests and I think you'll find there are bigger fish to fry.

Most LiveCode code bases - including mine - have many opportunities available to enhance performance of critical business-logic routines, things that directly affect users, that spending too much time on this one detail of one control on one OS will likely yield a very low return on investment.

Hopefully someone here with an interest in this will note the RQCC #, and you can cast a vote for it and move on to more interesting opportunities. Chances are there are repeat loops, accelerated rendering options, list and array traversal, and many other options awaiting you for very significant performance improvements in your app, using nothing more than the engine you have in your hands right now.

[mwieder]

The only open RQCC entry I see is #6855 from 2008, currrently with 12 votes. The drag on system resources has been reported as far back as 2003 in bug #466, and the code was tweaked "as far as possible" given the current OS constraints from 25% CPU time down to 15/20% in bug #3577 in 2006. No doubt it's time to revisit the tweaking and see if the OS appearance manager has changed now.

...and whatever you do, don't put more than one default button on the screen at once...

[FourthWorld]

..and whatever you do, don't put more than one default button on the screen at once...

...in any development tool on any platform; doing so would obviate the meaning of "default" as the one control that will respond to the Enter key.

[rrBUSS9EE]

I think control rendering is perhaps not a large enough blip on LC's radar as it should be. I might even say they have grown a bit complacent in this area, especially if you stop to consider the utter lack of properly rendered controls available on the most popular platforms they are aggressively marketing to (iOS and Android).

Developers now have to spend more time "mocking up" an interface with multiple artwork in multiple resolutions for these "supported" platforms than they do actual coding. Pretty unheard of within the history of high level authoring tools.

I feel quite strongly this is not a detail they are "spending too much time on". And while I don't disagree with your comments that there may be extreme challenges in rendering "native-looking" controls for multiple platforms, that is the size of the bite that LC has decided to chew.

[FourthWorld]

While somewhat related, those are three different categories of problems: general rendering performance, mobile-specific native controls, and the clock cycles needed for one control on one platform. The quickest solution for each of those may not be the best solution for the others, so we can expect to see improvement in some before others, depending on where the team is at the time with larger goals so it can all be done without having to do it over again later.

It seems that right now the focus is at the deepest level, the core rendering scheme for the engine, and there we've actually seen significant work over the last two versions of LiveCode - check out the tokens related to accelerated rendering in 5.0 and enhanced in 5.1.

Those were first discussed to outsiders at the NDA session at RevLive 2011 in San Jose, and are part of an ongoing effort to both increase overall performance while enhancing OS hooks to improve consistency with the rest of the OS.

I think we'll continue to see big strides in this area going forward.