Re: Cocoa application running very slow under 64 bit
Re: Cocoa application running very slow under 64 bit
- Subject: Re: Cocoa application running very slow under 64 bit
- From: Frank Illenberger <email@hidden>
- Date: Thu, 11 Sep 2008 14:49:49 +0200
Am 11.09.2008 um 14:04 schrieb Jean-Daniel Dupas:
Le 11 sept. 08 à 13:01, Frank Illenberger a écrit :
Hi there,
I migrated an existing cocoa application to run under x86_64 with
Xcode 3.1 / Mac OS 10.5.4. The app still runs fine under 32 bit
but when started in x86_64 mode, it runs about 3-4 times slower.
A shark profile reveals the following hot traces:
8.9% libgcc_s.1.dylib _Unwind_GetIPInfo
7.6% libgcc_s.1.dylib _Unwind_GetIPInfo
7.6% libgcc_s.1.dylib _Unwind_Backtrace
7.6% libobjc.A.dylib objc_addExceptionHandler
7.5% Unknown Library _CFDoExceptionOperation
7.2% Unknown Library _NSAppKitLock
1.5% Unknown Library -[NSView nextKeyView]
1.2% Unknown Library -[NSView _primitiveSetNextKeyView:]
0.8% Unknown Library +[NSControl cellClass] [unknown]
0.7% Unknown Library -[NSCell setMnemonicLocation:]
0.6% Unknown Library SetPlaceholderString
0.5% Unknown Library -[NSView previousKeyView]
0.2% Unknown Library -[NSControl
_setControlTextDelegateFromOld:toNew:]
These hot traces do not show up when I profile the app running
under 32 bit.
Does anybody know why a 64 bit app could be spending so much time
in these methods?
Is your program throwing a lots of exceptions ? The exception
handling mechanism is not the same between 32 bits and 64 bits
runtime. IIRC throwing an exception on the 64 bits runtime os a
lot more than on the 32 bits one.
With the 64bits runtime, it will properly unwind the stack and
call C++ dtor when needed (even if a pure objc program does not
require it), but with the 32bits runtime, it's just a longjmp call.
I am not throwing any exceptions in my code. If there are any, they
must get thrown from within the Cocoa frameworks. Is there a way to
track this? I added breakpoints at
objc_exception_throw
and
-[NSException initWithName:reason:userInfo:]
but they were not hit.
You may try to add a break point on objc_addExceptionHandler to find
where it is call.
I breaked at objc_addExceptionHandler and it gets called a lot. Here
are some example traces:
#0 0x00007fff8000ee72 in objc_addExceptionHandler ()
#1 0x00007fff801db290 in _CFDoExceptionOperation ()
#2 0x00007fff80f50d8a in _NSAppKitLock ()
#3 0x00007fff80f4ecd3 in +[NSColor redColor] ()
#4 0x00007fff80f4e5d5 in +[NSApplication initialize] ()
#0 0x00007fff8000ee72 in objc_addExceptionHandler ()
#1 0x00007fff801db290 in _CFDoExceptionOperation ()
#2 0x00007fff80f50d8a in _NSAppKitLock ()
#3 0x00007fff80f4ee88 in +[NSApplication sharedApplication] ()
#0 0x00007fff8000ee72 in objc_addExceptionHandler ()
#1 0x00007fff801db290 in _CFDoExceptionOperation ()
#2 0x00007fff80f50d8a in _NSAppKitLock ()
#3 0x00007fff81012dd3 in -[NSApplication(NSWindowCache)
_findWindowUsingCache:] ()
#4 0x00007fff80f8c20b in _DPSNextEvent ()
#5 0x00007fff80f8b6ff in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] ()
I guess this is normal behavior as these are regular cocoa calls. But
why does this consume so much CPU time?
Cheers
Frank
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden