LWM: Unusual cpu usage in window loaded from nib

Do any other LWM users see the following?
First, open Activity Monitor or a terminal window running top so that  
its continuous output is visible behind LWM's windows. Highlighting  
the line for LWM in Activity Monitor can make it easier to see if you  
sort the entries by cpu usage.

Compile  and load (or simply load) the example supplied with LWM at:
/Applications/LispWorks 4.4.5/Library/lib/4-4-0-0/examples/objc/area- 
calculator/area-calculator.lisp

execute:
(test-area-calculator)

when the single button CAPI interface appears click the button. When  
the Area Calculator window appears click on it to bring it foreground.

On my machine, whenever this window loaded from a nib file is  
foreground, LWM's cpu usage goes up to  about 7.5%. However, if any  
other LWM window is foreground - such as the Listener, or an Editor  
window - LWM's cpu usage is below 1%. Just for comparison, other  
Cocoa applications that load windows from nibs show a similarly low  
(~1%) cpu usage when the nib loaded window is foreground.

I get precisely the same high cpu usage results if I load the nib  
file by bypassing CAPI using objc:invoke and, when necessary,  
performSelectorOnMainThread:withObject:waitUntilDone: so this appears  
not to be a problem with CAPI but rather with LWM's public interface  
to the Objective-C runtime.

All of my tests were run from a factory install of LWM after a  
machine restart to eliminate the possibility that some misuse by me  
of the objc package had borked Apple's Objective-C runtime itself.

The good news is that it is not cumulative - cpu usage remains at  
~7.5% or a bit higher no matter how many windows loaded from a nib  
are open as long as any one of them is foreground.

First, can others confirm this? Second, any thoughts on why this is  
happening?

regards

Ralph

Raffael Cavallaro, Ph.D.
raffaelcavallaro@mac.com

Re: Unusual cpu usage in window loaded from nib

Yes, exactly the same behaviour here - 15.4% on powerbook titanium 1ghz

----- Original Message ----- 
From: "Raffael Cavallaro" <raffaelcavallaro@mac.com>
To: "Lisp Hug Lispworks" <lisp-hug@lispworks.com> 
<lisp-support@lispworks.com>
Sent: Sunday, June 05, 2005 6:11 PM
Subject: LWM: Unusual cpu usage in window loaded from nib


> Do any other LWM users see the following?
> First, open Activity Monitor or a terminal window running top so that  its 
> continuous output is visible behind LWM's windows. Highlighting  the line 
> for LWM in Activity Monitor can make it easier to see if you  sort the 
> entries by cpu usage.
>
> Compile  and load (or simply load) the example supplied with LWM at:
> /Applications/LispWorks 4.4.5/Library/lib/4-4-0-0/examples/objc/area- 
> calculator/area-calculator.lisp
>
> execute:
> (test-area-calculator)
>
> when the single button CAPI interface appears click the button. When  the 
> Area Calculator window appears click on it to bring it foreground.
>
> On my machine, whenever this window loaded from a nib file is  foreground, 
> LWM's cpu usage goes up to  about 7.5%. However, if any  other LWM window 
> is foreground - such as the Listener, or an Editor  window - LWM's cpu 
> usage is below 1%. Just for comparison, other  Cocoa applications that 
> load windows from nibs show a similarly low  (~1%) cpu usage when the nib 
> loaded window is foreground.
>
> I get precisely the same high cpu usage results if I load the nib  file by 
> bypassing CAPI using objc:invoke and, when necessary, 
> performSelectorOnMainThread:withObject:waitUntilDone: so this appears  not 
> to be a problem with CAPI but rather with LWM's public interface  to the 
> Objective-C runtime.
>
> All of my tests were run from a factory install of LWM after a  machine 
> restart to eliminate the possibility that some misuse by me  of the objc 
> package had borked Apple's Objective-C runtime itself.
>
> The good news is that it is not cumulative - cpu usage remains at  ~7.5% 
> or a bit higher no matter how many windows loaded from a nib  are open as 
> long as any one of them is foreground.
>
> First, can others confirm this? Second, any thoughts on why this is 
> happening?
>
> regards
>
> Ralph
>
> Raffael Cavallaro, Ph.D.
> raffaelcavallaro@mac.com
>

Re: LWM: Unusual cpu usage in window loaded from nib

On Jun 5, 2005, at 9:11 AM, Raffael Cavallaro wrote:

> On my machine, whenever this window loaded from a nib file is  
> foreground, LWM's cpu usage goes up to  about 7.5%. However, if any  
> other LWM window is foreground - such as the Listener, or an Editor  
> window - LWM's cpu usage is below 1%. Just for comparison, other  
> Cocoa applications that load windows from nibs show a similarly low  
> (~1%) cpu usage when the nib loaded window is foreground.
>

[snip]

> First, can others confirm this? Second, any thoughts on why this is  
> happening?

I've seen this sort of behavior outside of LispWorks as well (but not  
in every app). In general it seems to happen when the window in  
question (window, sheet, or dialog) has a button which has 'return'  
as the key equivalent. That splashy little pulsing "Compute" button  
in this case is the CPU sucker. To verify I opened the NIB, removed  
the key equivalent on the "Compute" button and re-ran the test. The  
result was the typical ~1% CPU load and no more pulsing button.

I've never had much luck running GDB against lispworks but the  
ThreadViewer.app has been useful. If you change the NIB back such  
that the "Compute" button is bound to Return, launch ThreadViewer.app  
and attach to LispWorks, re-run the example, and then bring the NIB  
based window in and out of the foreground you can clearly see one  
thread's activity changing. When I clicked on the thread in question  
to look at its stack trace I noticed the following (area calculator  
window was in the background):

semaphore_wait_signal_trap
pthread_cond_wait
-[NSConditionLock lockWhenCondition:]
-[NSUIHeartBeat _heartBeatThread:]
forkThreadForFunction
_pthread_body

....as to a particular solution or whether the CPU drain is even  
avoidable I can't say...

Cheers,

-greg

_______________________________________________________
Greg Wuller                             greg@wuller.com
_______________________________________________________