NSInvocationOperation Performance Question

Discussion in 'Mac Programming' started by Avizzv92, Feb 12, 2011.

  1. Avizzv92 macrumors regular

    Joined:
    Mar 23, 2008
    #1
    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...

    Code:
    -(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.

    Code:
     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!
     
  2. kainjow, Feb 12, 2011
    Last edited: Feb 12, 2011

    kainjow Moderator emeritus

    kainjow

    Joined:
    Jun 15, 2000
    #2
    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?
     
  3. Avizzv92 thread starter macrumors regular

    Joined:
    Mar 23, 2008
    #3
    It's being created in my init method like so.

    Code:
    que = [[NSOperationQueue alloc]init];
    By stack frame do you mean from the Time Profiler?
     
  4. kainjow Moderator emeritus

    kainjow

    Joined:
    Jun 15, 2000
    #4
    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.
     
  5. Avizzv92 thread starter macrumors regular

    Joined:
    Mar 23, 2008
    #5
    Here is the main thread and the second thread.

    [​IMG]

    [​IMG]
     
  6. mfram macrumors 65816

    Joined:
    Jan 23, 2010
    Location:
    San Diego, CA USA
    #6
    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.
     
  7. kainjow Moderator emeritus

    kainjow

    Joined:
    Jun 15, 2000
    #7
    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.
     

Share This Page