macOS NSInvocationOperation Performance Question

[Avizzv92]

I have a method in my application that goes through all subscribed feeds in my application's PubSub Client and marks all the entries as read. When the number of entries it has to go through gets up into the hundreds this take up a significant amount of time, relatively speaking.

The code for the method looks like this...

-(void)markAllReadOperation
{
    NSArray *feeds = [[PSClient applicationClient]feeds];
    
    for(PSFeed *feed in feeds)
        for(PSEntry *entry in [feed entries])
            entry.read = YES;
}

I want this to be able to run in the background while the user would still be able to interact with the UI in the foreground. So I set up a NSInvocationOpertion and NSInvocationQueue to handle this operation. The code looks like this.

 NSInvocationOperation *opr = [[NSInvocationOperation alloc]initWithTarget:self selector:@selector(markAllReadOperation) object:nil];
    [queue addOperation:opr];
    [opr release];

Unfortunately the UI is very unresponsive when this operation is taking place and has extreme lag. I'm unsure as to why this is the case, I was under the impression that this could be avoided when using NSInvocationOperation.

I haven't used Time Profiler in instruments before, nor do I know what exactly would I be looking for. From what I can tell, it seems PubSub is taking up the highest percentage while the event is occurring. While exploring the symbol names my method is occurring on "_dispatch_worker_thread2" while the actual PubSub operations like "sendChangesSinceDate" (which is taking up the highest percentage while my operation is working) is occuring on the "Thread 0x5565 : Main Thread". Does this seem correct?

Any help is appreciated, thanks in advance!

 

[kainjow]

How is "queue" created? I ask because it's possible queue could be the mainQueue which isn't what you'd want.

If your method is indeed working on a background thread, and PubSub is automatically doing things in the main thread, then it probably doesn't support being accessed from a thread other than man.

Can you post a screenshot of the stack frame for the background thread?

 

[Avizzv92]

It's being created in my init method like so.

que = [[NSOperationQueue alloc]init];

By stack frame do you mean from the Time Profiler?

 

[kainjow]

I mean when it's lagging, pause the program and go into the debugger and then you can see the stack trace of your threads to see what they're doing at that point.

 

[Avizzv92]

Here is the main thread and the second thread.

 

[mfram]

Looks like maybe some kind of locking contention. Possibly in the memory pool code. Just a guess. If your program isn't designed with multi-threading in mind and you are just letting Cocoa do it for you, maybe it isn't working optimally.

 

[kainjow]

Maybe while you're doing this operation, set a flag so that feed:didChangeFlagsInEntries: queues up what it's doing until the operation completes. But either way, it appears that delegate method is the culprit.