Re: Operations Beachball
On Dec 4, 2012, at 11:46 PM, Gerriet M. Denkmann wrote: > When I add 8 or more operations to NSOperationQueue (using > NSOperationQueueDefaultMaxConcurrentOperationCount concurrent ops) , > - then switch to some other app, > - then try to make my app active again, I get a beach-ball. > My app becomes responsive again, when all operations have finished. OK, that is nuts, and seems to confirm what Kyle said on one of the many other threads you started: >> NSOperationQueue uses KVO for dependency tracking and queue width >> management. In 10.7, the implementation was apparently changed to thunk all >> KVO ops onto the main thread; I'm guessing this fixed a bug by serializing >> all state changes. It sounds like the large numbers of isCanceled calls your operation is making are somehow causing activity on the main thread that’s blocking other stuff. Very weird. PLEASE take a sample of the app while it’s in the beachballed state and look at what’s going on on the main thread and the GCD threads used by the operation queue. That should give clues about what’s happening. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Operations Beachball
On 4 Dec 2012, at 18:29, Jens Alfke wrote: > On Dec 4, 2012, at 3:48 AM, Gerriet M. Denkmann wrote: > >> My app creates lots of MyOperations (subclass of NSOperation) and puts them >> into an NSOperationQueue. >> I would expect that the app thus remains responsive, but sometimes it is not. > > Welcome to the joys of multithreaded programming. :-P You have to be pretty > careful about how you do things, or all sorts of unintuitive and flaky > behaviors can result. > >> + 1343 >> MenuBarInstance::Show(MenuBarAnimationStyle, unsigned char, unsigned char, >> unsigned char) (in HIToolbox) + 625 [0x7fff90ea5063] >> + 1343 BroadcastToolboxMessage (in HIToolbox) + >> 294 [0x7fff90e6e12a] >> + 1343 >> HIS_XPC_CFNotificationCenterPostNotification (in HIServices) + 532 >> [0x7fff8e57f174] >> + 1343 CFNotificationCenterPostNotification >> (in CoreFoundation) + 115 [0x7fff95edbbf3] >> + 1343 _CFXNotificationPost (in >> CoreFoundation) + 1109 [0x7fff95ecced5] >> + 1343 -[_NSDNXPCConnection >> sendMessage:waitForAck:] (in CoreFoundation) + 347 [0x7fff95fec12b] >> + 1343 _dispatch_semaphore_wait_slow >> (in libdispatch.dylib) + 241 [0x7fff97ed0486] >> + 1343 semaphore_wait_trap (in >> libsystem_kernel.dylib) + 10 [0x7fff95ac86c2] >> >> >> I have no idea, what this means. >> Maybe someone can enlighten me. > > The main thread is sending a cross-process (XPC) message and waiting for a > reply. Presumably this has something to do with arbitration of the menu bar > state since the menu bar is a shared resource between apps? But it doesn’t > seem related to anything you’re doing. Is it possible that the XPC that's being waited for here is stalled because whatever's meant to respond to it is a default priority GCD-dispatched block that can't run because GCD has scheduled a lot of your operations, also at the default priority, and won't schedule another (e.g. the one to reply to that message) until the load lightens? I know this sounds unlikely, but it bit me in an iOS project - I was seeing multi-second stalls on the main thread because of this. I 'solved' my problem by lowering the CGD queue priority of my operations. This took care of the large stalls, but to actually get a non-jerky UI, I also had to limit the maxConcurrentOperationCount on my queue to stop GCD from scheduling too many of the operations at once and bogging down the CPU. GCD scheduled too many otherwise because it was fooled into thinking there were resources available whenever a running operation stalled on I/O for a short period. Full details, including samples, are here: https://devforums.apple.com/message/756881. One of the selling points of GCD is that it manages all of this for you, of course, but I've found that's not the case when multiple parts of the system are expecting to be able to use it at once and don't coordinate - especially if there's I/O going on anywhere. Jamie. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Operations Beachball
On 5 Dec 2012, at 15:57, Joar Wingfors wrote:
> What happens if you remove the "isCancelled" checks?
No effect on blocking.
> How do you create your operation queue?
if ( self.operationQueue == nil )
{
self.operationQueue = [ [ NSOperationQueue alloc ] init ];
#ifdef OBSERVE_OPERATION_COUNT <-- has no effect on blocking
[ self.operationQueue addObserver:self
forKeyPath:
kOperationCount
options:
0
context:
(__bridge void *)kOperationCount
];
#endif
}
else
{
[ self.operationQueue cancelAllOperations ];
};
> What is the max concurrent operation count of the queue? If
> NSOperationQueueDefaultMaxConcurrentOperationCount, what happens if you set
> it to (processorCount) instead?
With (processorCount) it does no longer block. Very strange. This I did not
expect at all.
With NSOperationQueueDefaultMaxConcurrentOperationCount the app gets blocked
with more than 8 operations.
> When you take a CPU sample of the process, what are your worker threads
> mainly doing (work, or being stuck)?
All seem to be in in their main method busy adding square-roots.
>>
>>
>> I made a test project with this Operation:
>>
>> @implementation GmdOperationBasis
>> - (void)main
>> {
>> if ( [ self isCancelled ] ) return;
>> double sum = 8;
>> for( NSUInteger i = 0; i < 13383; i++ )
>> {
>> if ( [ self isCancelled ] ) return;
>> double j = (double)i;
>> sum += sqrt(j);
>> };
>> }
>> @end
>>
>> When I add less than 8 operations to the queue, all is fine.
>>
>> When I add 8 or more operations to NSOperationQueue (using
>> NSOperationQueueDefaultMaxConcurrentOperationCount concurrent ops) ,
>> - then switch to some other app,
>> - then try to make my app active again, I get a beach-ball.
>>
>> My app becomes responsive again, when all operations have finished.
>>
>> processorCount = 8 (as reported by NSProcessInfo).
>>
>> 10.8.2. Xcode 4.5.2.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Operations Beachball
What happens if you remove the "isCancelled" checks?
How do you create your operation queue?
What is the max concurrent operation count of the queue? If
NSOperationQueueDefaultMaxConcurrentOperationCount, what happens if you set it
to (processorCount) instead?
When you take a CPU sample of the process, what are your worker threads mainly
doing (work, or being stuck)?
Joar
On 4 dec 2012, at 23:46, Gerriet M. Denkmann wrote:
>
> On 5 Dec 2012, at 01:29, Jens Alfke wrote:
>
>>
>> On Dec 4, 2012, at 3:48 AM, Gerriet M. Denkmann wrote:
>>
>>> My app creates lots of MyOperations (subclass of NSOperation) and puts them
>>> into an NSOperationQueue.
>>> I would expect that the app thus remains responsive, but sometimes it is
>>> not.
>
>
> I made a test project with this Operation:
>
> @implementation GmdOperationBasis
> - (void)main
> {
> if ( [ self isCancelled ] ) return;
> double sum = 8;
> for( NSUInteger i = 0; i < 13383; i++ )
> {
> if ( [ self isCancelled ] ) return;
> double j = (double)i;
> sum += sqrt(j);
> };
> }
> @end
>
> When I add less than 8 operations to the queue, all is fine.
>
> When I add 8 or more operations to NSOperationQueue (using
> NSOperationQueueDefaultMaxConcurrentOperationCount concurrent ops) ,
> - then switch to some other app,
> - then try to make my app active again, I get a beach-ball.
>
> My app becomes responsive again, when all operations have finished.
>
> processorCount = 8 (as reported by NSProcessInfo).
>
> 10.8.2. Xcode 4.5.2.
>
>
> Kind regards,
>
> Gerriet.
>
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/joar%40joar.com
>
> This email sent to j...@joar.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Operations Beachball
On 5 Dec 2012, at 01:29, Jens Alfke wrote:
>
> On Dec 4, 2012, at 3:48 AM, Gerriet M. Denkmann wrote:
>
>> My app creates lots of MyOperations (subclass of NSOperation) and puts them
>> into an NSOperationQueue.
>> I would expect that the app thus remains responsive, but sometimes it is not.
I made a test project with this Operation:
@implementation GmdOperationBasis
- (void)main
{
if ( [ self isCancelled ] ) return;
double sum = 8;
for( NSUInteger i = 0; i < 13383; i++ )
{
if ( [ self isCancelled ] ) return;
double j = (double)i;
sum += sqrt(j);
};
}
@end
When I add less than 8 operations to the queue, all is fine.
When I add 8 or more operations to NSOperationQueue (using
NSOperationQueueDefaultMaxConcurrentOperationCount concurrent ops) ,
- then switch to some other app,
- then try to make my app active again, I get a beach-ball.
My app becomes responsive again, when all operations have finished.
processorCount = 8 (as reported by NSProcessInfo).
10.8.2. Xcode 4.5.2.
Kind regards,
Gerriet.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Operations Beachball
On Dec 4, 2012, at 4:29 AM, Gerriet M. Denkmann wrote:
> My app creates lots of MyOperations (subclass of NSOperation) and puts them
> into an NSOperationQueue.
>
> I would expect that the app thus remains responsive, but sometimes it is not.
>
> A sure way to beach-ball my app is: start it with a few hundred operations
> (which will take about 20 seconds to finish).
> Make some other app active.
> Try to make my app active again - it's panel stays grey and after a few
> seconds the cursor will turn into a beach-ball.
>
> These MyOperations interact with their controller in two ways:
>
> 1. they do once at start: [ controller dataStringFor: row ];
>
> The controller has:
>
> - (NSString *) dataStringFor: (NSUInteger)row
> {
> @synchronized(self)
> {
> if ( self.stringArray == nil ) { create it - takes some time,
> but happens only once};
> }
> return self.stringArray[row];
> }
>
>
> 2. When MyOperations have finished their work they call: [ controller done:
> row result: someNumber ];
>
> The controller has:
>
> - (void) done: (NSUInteger) row result: (NSUInteger) someNumber
> {
>@synchronized(self)
> {
> [ self.rowsToDo removeIndex: row ]; //
> NSMutableIndexSet
> };
>
> // sometimes do some logging, update user interface - but only
> every few seconds
> }
>
> So, why the beach-ball? What am I doing wrong? How to debug this? Why does
> the app-switch make the beach-ball appear?
I don't know that this will make a big difference, but since you're dealing
with a performance issue, @synchronized is known to be much slower than other
methods of synchronization. You could try replacing this with dispatch_sync on
a serial queue, a spin lock, or a mutex and see if it helps at all.
Charles
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Operations Beachball
On Dec 4, 2012, at 3:48 AM, Gerriet M. Denkmann wrote: > My app creates lots of MyOperations (subclass of NSOperation) and puts them > into an NSOperationQueue. > I would expect that the app thus remains responsive, but sometimes it is not. Welcome to the joys of multithreaded programming. :-P You have to be pretty careful about how you do things, or all sorts of unintuitive and flaky behaviors can result. >+ 1343 > MenuBarInstance::Show(MenuBarAnimationStyle, unsigned char, unsigned char, > unsigned char) (in HIToolbox) + 625 [0x7fff90ea5063] >+ 1343 BroadcastToolboxMessage (in HIToolbox) + > 294 [0x7fff90e6e12a] >+ 1343 > HIS_XPC_CFNotificationCenterPostNotification (in HIServices) + 532 > [0x7fff8e57f174] >+ 1343 CFNotificationCenterPostNotification > (in CoreFoundation) + 115 [0x7fff95edbbf3] >+ 1343 _CFXNotificationPost (in > CoreFoundation) + 1109 [0x7fff95ecced5] >+ 1343 -[_NSDNXPCConnection > sendMessage:waitForAck:] (in CoreFoundation) + 347 [0x7fff95fec12b] >+ 1343 _dispatch_semaphore_wait_slow > (in libdispatch.dylib) + 241 [0x7fff97ed0486] >+ 1343 semaphore_wait_trap (in > libsystem_kernel.dylib) + 10 [0x7fff95ac86c2] > > > I have no idea, what this means. > Maybe someone can enlighten me. The main thread is sending a cross-process (XPC) message and waiting for a reply. Presumably this has something to do with arbitration of the menu bar state since the menu bar is a shared resource between apps? But it doesn’t seem related to anything you’re doing. You didn’t post the rest of the sample output. My guess is that some other thread is running code that, for some reason, is holding whatever lock XPC needs. Are you calling AppKit from your background operations? (That’s almost certainly a bad idea!) From this comment it sounds like the answer is yes: > // sometimes do some logging, update user interface - but only > every few seconds DO NOT do anything UI-related from a background thread unless you _really_ know what you’re doing, or you can find yourself in exactly this sort of trouble. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Operations Beachball
On 4 Dec 2012, at 11:48, Gerriet M. Denkmann wrote: > > On 4 Dec 2012, at 18:10, Roland King wrote: > >> Can you not run Instruments from the 'Profile' button on Xcode? It should >> start the process and attach to it and go from there. > > I got the Leaks Instrument to work this way (no Leaks) But all other > Instruments just prompted repeatedly for an admin password but did not do > anything at all. > > Activity Monitor gave me a Sample. Here is the main thread: > > Call graph: > 1343 Thread_3102216 DispatchQueue_1: com.apple.main-thread (serial) > + 1343 start (in libdyld.dylib) + 1 [0x7fff983887e1] > + 1343 NSApplicationMain (in AppKit) + 869 [0x7fff96809cb6] > + 1343 -[NSApplication run] (in AppKit) + 517 [0x7fff96865283] > + 1343 -[NSApplication > nextEventMatchingMask:untilDate:inMode:dequeue:] (in AppKit) + 128 > [0x7fff9686ded2] > + 1343 _DPSNextEvent (in AppKit) + 685 [0x7fff9686e613] > + 1343 BlockUntilNextEventMatchingListInMode (in HIToolbox) + 62 > [0x7fff90ec2cd3] > + 1343 ReceiveNextEventCommon (in HIToolbox) + 217 > [0x7fff90ec2db7] > + 1343 AcquireEventFromQueue (in HIToolbox) + 561 > [0x7fff90eccf8f] > + 1343 _NotifyEventLoopObservers (in HIToolbox) + 155 > [0x7fff90e9b6e0] > + 1343 HIApplication::EventObserver(unsigned int, > OpaqueEventRef*, void*) (in HIToolbox) + 193 [0x7fff90ecd407] > + 1343 HIApplication::HandleActivated(OpaqueEventRef*, > unsigned char, OpaqueWindowPtr*) (in HIToolbox) + 177 [0x7fff90ecfe0f] > + 1343 SetMenuBarObscured (in HIToolbox) + 221 > [0x7fff90ed0144] > + 1343 MenuBarInstance::Show(MenuBarAnimationStyle, > unsigned char, unsigned char, unsigned char) (in HIToolbox) + 625 > [0x7fff90ea5063] > + 1343 BroadcastToolboxMessage (in HIToolbox) + > 294 [0x7fff90e6e12a] > + 1343 > HIS_XPC_CFNotificationCenterPostNotification (in HIServices) + 532 > [0x7fff8e57f174] > + 1343 CFNotificationCenterPostNotification > (in CoreFoundation) + 115 [0x7fff95edbbf3] > + 1343 _CFXNotificationPost (in > CoreFoundation) + 1109 [0x7fff95ecced5] > + 1343 -[_NSDNXPCConnection > sendMessage:waitForAck:] (in CoreFoundation) + 347 [0x7fff95fec12b] > + 1343 _dispatch_semaphore_wait_slow > (in libdispatch.dylib) + 241 [0x7fff97ed0486] > + 1343 semaphore_wait_trap (in > libsystem_kernel.dylib) + 10 [0x7fff95ac86c2] > > > I have no idea, what this means. > Maybe someone can enlighten me. > > Gerriet. > Your app is blocking waiting for a semaphore. The extract below is from http://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KernelProgramming/synchronization/synchronization.html A semaphore is much like a lock, except that a finite number of threads can hold it simultaneously. Semaphores can be thought of as being much like piles of tokens. Multiple threads can take these tokens, but when there are none left, a thread must wait until another thread returns one. It is important to note that semaphores can be implemented in many different ways, so Mach semaphores may not behave in the same way as semaphores on other platforms. It looks as if part of the menu system needs a particular semaphore which is currently blocked as a result of other operations. I don't have a solution but the following is related. http://stackoverflow.com/questions/13148684/deadlock-using-dispatch-semaphore-t-in-a-concurrent-queue Jonathan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Operations Beachball
On 4 Dec 2012, at 18:31, "jonat...@mugginsoft.com"
wrote:
>
>
> On 4 Dec 2012, at 10:29, Gerriet M. Denkmann wrote:
>
>> My app creates lots of MyOperations (subclass of NSOperation) and puts them
>> into an NSOperationQueue.
>>
>> I would expect that the app thus remains responsive, but sometimes it is not.
>>
>> A sure way to beach-ball my app is: start it with a few hundred operations
>> (which will take about 20 seconds to finish).
>> Make some other app active.
>> Try to make my app active again - it's panel stays grey and after a few
>> seconds the cursor will turn into a beach-ball.
>>
>> These MyOperations interact with their controller in two ways:
>>
>> 1. they do once at start: [ controller dataStringFor: row ];
>>
>> The controller has:
>>
>> - (NSString *) dataStringFor: (NSUInteger)row
>> {
>> @synchronized(self)
>> {
>> if ( self.stringArray == nil ) { create it - takes some time,
>> but happens only once};
>> }
>> return self.stringArray[row];
>> }
>>
> Does the app also access the controller object?
The controller is also the app delegate.
> You are locking the controller so the main app's performance may also be
> affected if the controller is shared with the main thread.
The code inside @synchronized is absolute minimal. I will be used every 50
milli-seconds. Cannot believe this blocks the controller.
>
>
> In the absence of Instruments I would at least experiment with no oping the
> @synchronized methods and try and exclude them as a problem source.
Did comment out both @synchronized lines - same problem - no change at all.
Kind regards,
Gerriet.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Operations Beachball
On 4 Dec 2012, at 18:10, Roland King wrote:
> Can you not run Instruments from the 'Profile' button on Xcode? It should
> start the process and attach to it and go from there.
I got the Leaks Instrument to work this way (no Leaks) But all other
Instruments just prompted repeatedly for an admin password but did not do
anything at all.
Activity Monitor gave me a Sample. Here is the main thread:
Call graph:
1343 Thread_3102216 DispatchQueue_1: com.apple.main-thread (serial)
+ 1343 start (in libdyld.dylib) + 1 [0x7fff983887e1]
+ 1343 NSApplicationMain (in AppKit) + 869 [0x7fff96809cb6]
+ 1343 -[NSApplication run] (in AppKit) + 517 [0x7fff96865283]
+ 1343 -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] (in AppKit) + 128
[0x7fff9686ded2]
+ 1343 _DPSNextEvent (in AppKit) + 685 [0x7fff9686e613]
+ 1343 BlockUntilNextEventMatchingListInMode (in HIToolbox) + 62
[0x7fff90ec2cd3]
+ 1343 ReceiveNextEventCommon (in HIToolbox) + 217
[0x7fff90ec2db7]
+ 1343 AcquireEventFromQueue (in HIToolbox) + 561
[0x7fff90eccf8f]
+ 1343 _NotifyEventLoopObservers (in HIToolbox) + 155
[0x7fff90e9b6e0]
+ 1343 HIApplication::EventObserver(unsigned int,
OpaqueEventRef*, void*) (in HIToolbox) + 193 [0x7fff90ecd407]
+ 1343 HIApplication::HandleActivated(OpaqueEventRef*,
unsigned char, OpaqueWindowPtr*) (in HIToolbox) + 177 [0x7fff90ecfe0f]
+ 1343 SetMenuBarObscured (in HIToolbox) + 221
[0x7fff90ed0144]
+ 1343 MenuBarInstance::Show(MenuBarAnimationStyle,
unsigned char, unsigned char, unsigned char) (in HIToolbox) + 625
[0x7fff90ea5063]
+ 1343 BroadcastToolboxMessage (in HIToolbox) +
294 [0x7fff90e6e12a]
+ 1343
HIS_XPC_CFNotificationCenterPostNotification (in HIServices) + 532
[0x7fff8e57f174]
+ 1343 CFNotificationCenterPostNotification
(in CoreFoundation) + 115 [0x7fff95edbbf3]
+ 1343 _CFXNotificationPost (in
CoreFoundation) + 1109 [0x7fff95ecced5]
+ 1343 -[_NSDNXPCConnection
sendMessage:waitForAck:] (in CoreFoundation) + 347 [0x7fff95fec12b]
+ 1343 _dispatch_semaphore_wait_slow
(in libdispatch.dylib) + 241 [0x7fff97ed0486]
+ 1343 semaphore_wait_trap (in
libsystem_kernel.dylib) + 10 [0x7fff95ac86c2]
I have no idea, what this means.
Maybe someone can enlighten me.
Gerriet.
>
> On 4 Dec, 2012, at 7:02 PM, "Gerriet M. Denkmann"
> wrote:
>
>>
>> On 4 Dec 2012, at 17:49, Mike Abdullah wrote:
>>
>>> You have a performance problem. Thus you should use Instruments to see what
>>> is going on, rather than hope we can tell you from vague snippets of code.
>>
>> Maybe I should use Instruments, problem is: I cannot.
>>
>> I start Instruments, select some template (e.g. Leaks), attach to a
>> (user-)process, click "Record", and now a panel comes up (which I have never
>> seen before): "Instruments wants permission to analyse other processes. Type
>> an admin...".
>> Annoying, but maybe necessary.
>>
>> But now nothing happens, i.e no recording takes place.
>> What magic do I have to perform to make Instruments (4.5) work?
>> (I asked this on the Xcode list already, but got no answer).
>>
>>>
>>> On 4 Dec 2012, at 10:29, "Gerriet M. Denkmann" wrote:
>>>
My app creates lots of MyOperations (subclass of NSOperation) and puts
them into an NSOperationQueue.
I would expect that the app thus remains responsive, but sometimes it is
not.
A sure way to beach-ball my app is: start it with a few hundred operations
(which will take about 20 seconds to finish).
Make some other app active.
Try to make my app active again - it's panel stays grey and after a few
seconds the cursor will turn into a beach-ball.
These MyOperations interact with their controller in two ways:
1. they do once at start: [ controller dataStringFor: row ];
The controller has:
- (NSString *) dataStringFor: (NSUInteger)row
{
@synchronized(self)
{
if ( self.stringArray == nil ) { create it - takes some time,
but happens only once};
}
return self.stringArray[row];
}
2. When MyOperations have finished their work they call: [ controller
done: row result: someNumber ];
The controller has:
- (void) done: (NSUInteger) row result: (NSUInteger) someNumber
{
@synchronized(self)
{
[ self.rowsToDo removeIndex: row ]; //
NSMutableIndexSet
};
// so
Re: Operations Beachball
On 4 Dec 2012, at 10:29, Gerriet M. Denkmann wrote:
> My app creates lots of MyOperations (subclass of NSOperation) and puts them
> into an NSOperationQueue.
>
> I would expect that the app thus remains responsive, but sometimes it is not.
>
> A sure way to beach-ball my app is: start it with a few hundred operations
> (which will take about 20 seconds to finish).
> Make some other app active.
> Try to make my app active again - it's panel stays grey and after a few
> seconds the cursor will turn into a beach-ball.
>
> These MyOperations interact with their controller in two ways:
>
> 1. they do once at start: [ controller dataStringFor: row ];
>
> The controller has:
>
> - (NSString *) dataStringFor: (NSUInteger)row
> {
> @synchronized(self)
> {
> if ( self.stringArray == nil ) { create it - takes some time,
> but happens only once};
> }
> return self.stringArray[row];
> }
>
Does the app also access the controller object?
You are locking the controller so the main app's performance may also be
affected if the controller is shared with the main thread.
In the absence of Instruments I would at least experiment with no oping the
@synchronized methods and try and exclude them as a problem source.
Jonathan
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Operations Beachball
Can you not run Instruments from the 'Profile' button on Xcode? It should start
the process and attach to it and go from there.
On 4 Dec, 2012, at 7:02 PM, "Gerriet M. Denkmann" wrote:
>
> On 4 Dec 2012, at 17:49, Mike Abdullah wrote:
>
>> You have a performance problem. Thus you should use Instruments to see what
>> is going on, rather than hope we can tell you from vague snippets of code.
>
> Maybe I should use Instruments, problem is: I cannot.
>
> I start Instruments, select some template (e.g. Leaks), attach to a
> (user-)process, click "Record", and now a panel comes up (which I have never
> seen before): "Instruments wants permission to analyse other processes. Type
> an admin...".
> Annoying, but maybe necessary.
>
> But now nothing happens, i.e no recording takes place.
> What magic do I have to perform to make Instruments (4.5) work?
> (I asked this on the Xcode list already, but got no answer).
>
>>
>> On 4 Dec 2012, at 10:29, "Gerriet M. Denkmann" wrote:
>>
>>> My app creates lots of MyOperations (subclass of NSOperation) and puts them
>>> into an NSOperationQueue.
>>>
>>> I would expect that the app thus remains responsive, but sometimes it is
>>> not.
>>>
>>> A sure way to beach-ball my app is: start it with a few hundred operations
>>> (which will take about 20 seconds to finish).
>>> Make some other app active.
>>> Try to make my app active again - it's panel stays grey and after a few
>>> seconds the cursor will turn into a beach-ball.
>>>
>>> These MyOperations interact with their controller in two ways:
>>>
>>> 1. they do once at start: [ controller dataStringFor: row ];
>>>
>>> The controller has:
>>>
>>> - (NSString *) dataStringFor: (NSUInteger)row
>>> {
>>> @synchronized(self)
>>> {
>>> if ( self.stringArray == nil ) { create it - takes some time,
>>> but happens only once};
>>> }
>>> return self.stringArray[row];
>>> }
>>>
>>>
>>> 2. When MyOperations have finished their work they call: [ controller
>>> done: row result: someNumber ];
>>>
>>> The controller has:
>>>
>>> - (void) done: (NSUInteger) row result: (NSUInteger) someNumber
>>> {
>>> @synchronized(self)
>>> {
>>> [ self.rowsToDo removeIndex: row ]; //
>>> NSMutableIndexSet
>>> };
>>>
>>> // sometimes do some logging, update user interface - but only
>>> every few seconds
>>> }
>>>
>>> So, why the beach-ball? What am I doing wrong? How to debug this? Why does
>>> the app-switch make the beach-ball appear?
>>>
>>> Gerriet.
>>>
>>> 10.8.2, Arc
>>>
>>>
>>>
>>> ___
>>>
>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>>
>>> 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:
>>> https://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net
>>>
>>> This email sent to cocoa...@mikeabdullah.net
>>
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
>
> This email sent to r...@rols.org
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Operations Beachball
On 4 Dec 2012, at 17:49, Mike Abdullah wrote:
> You have a performance problem. Thus you should use Instruments to see what
> is going on, rather than hope we can tell you from vague snippets of code.
Maybe I should use Instruments, problem is: I cannot.
I start Instruments, select some template (e.g. Leaks), attach to a
(user-)process, click "Record", and now a panel comes up (which I have never
seen before): "Instruments wants permission to analyse other processes. Type an
admin...".
Annoying, but maybe necessary.
But now nothing happens, i.e no recording takes place.
What magic do I have to perform to make Instruments (4.5) work?
(I asked this on the Xcode list already, but got no answer).
>
> On 4 Dec 2012, at 10:29, "Gerriet M. Denkmann" wrote:
>
>> My app creates lots of MyOperations (subclass of NSOperation) and puts them
>> into an NSOperationQueue.
>>
>> I would expect that the app thus remains responsive, but sometimes it is not.
>>
>> A sure way to beach-ball my app is: start it with a few hundred operations
>> (which will take about 20 seconds to finish).
>> Make some other app active.
>> Try to make my app active again - it's panel stays grey and after a few
>> seconds the cursor will turn into a beach-ball.
>>
>> These MyOperations interact with their controller in two ways:
>>
>> 1. they do once at start: [ controller dataStringFor: row ];
>>
>> The controller has:
>>
>> - (NSString *) dataStringFor: (NSUInteger)row
>> {
>> @synchronized(self)
>> {
>> if ( self.stringArray == nil ) { create it - takes some time,
>> but happens only once};
>> }
>> return self.stringArray[row];
>> }
>>
>>
>> 2. When MyOperations have finished their work they call: [ controller done:
>> row result: someNumber ];
>>
>> The controller has:
>>
>> - (void) done: (NSUInteger) row result: (NSUInteger) someNumber
>> {
>> @synchronized(self)
>> {
>> [ self.rowsToDo removeIndex: row ]; //
>> NSMutableIndexSet
>> };
>>
>> // sometimes do some logging, update user interface - but only
>> every few seconds
>> }
>>
>> So, why the beach-ball? What am I doing wrong? How to debug this? Why does
>> the app-switch make the beach-ball appear?
>>
>> Gerriet.
>>
>> 10.8.2, Arc
>>
>>
>>
>> ___
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net
>>
>> This email sent to cocoa...@mikeabdullah.net
>
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Operations Beachball
You have a performance problem. Thus you should use Instruments to see what is
going on, rather than hope we can tell you from vague snippets of code.
On 4 Dec 2012, at 10:29, "Gerriet M. Denkmann" wrote:
> My app creates lots of MyOperations (subclass of NSOperation) and puts them
> into an NSOperationQueue.
>
> I would expect that the app thus remains responsive, but sometimes it is not.
>
> A sure way to beach-ball my app is: start it with a few hundred operations
> (which will take about 20 seconds to finish).
> Make some other app active.
> Try to make my app active again - it's panel stays grey and after a few
> seconds the cursor will turn into a beach-ball.
>
> These MyOperations interact with their controller in two ways:
>
> 1. they do once at start: [ controller dataStringFor: row ];
>
> The controller has:
>
> - (NSString *) dataStringFor: (NSUInteger)row
> {
> @synchronized(self)
> {
> if ( self.stringArray == nil ) { create it - takes some time,
> but happens only once};
> }
> return self.stringArray[row];
> }
>
>
> 2. When MyOperations have finished their work they call: [ controller done:
> row result: someNumber ];
>
> The controller has:
>
> - (void) done: (NSUInteger) row result: (NSUInteger) someNumber
> {
>@synchronized(self)
> {
> [ self.rowsToDo removeIndex: row ]; //
> NSMutableIndexSet
> };
>
> // sometimes do some logging, update user interface - but only
> every few seconds
> }
>
> So, why the beach-ball? What am I doing wrong? How to debug this? Why does
> the app-switch make the beach-ball appear?
>
> Gerriet.
>
> 10.8.2, Arc
>
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40mikeabdullah.net
>
> This email sent to cocoa...@mikeabdullah.net
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
