Mac, iOS? If iOS, device or sim? IPad? Try publishing and not running through Xcode.
Sent from my iPhone > On May 22, 2016, at 12:48 PM, Seth Willits <sli...@araelium.com> wrote: > > I'm thoroughly confused and increasingly desperate. *All* of the threads in > my application periodically are blocked for 30-50 ms pretty regularly, about > every 150 ms. > > I'm processing a bunch of data via NSOperations running in a couple of > "serial" (maxConcurrentOperationCount = 1) NSOperationQueues. Each of the > operations is itself synchronous (overriding -main). Everything works as > expected. For performance reasons, I want to move one of the operation types > to being asynchronous and eventually allow two concurrent operations. > > So to start with, I took the synchronous code in -main, moved it into -start, > and added the appropriate KVO notifications for isExecuting, isFinished, and > implemented the right accessors etc. So effectively the operation says it's > asynchronous, but all of its work is actually done in -start, followed by > notifying it's finished. The work is all done correctly, but I noticed it > took significantly longer to complete. > > Thankfully I have a nifty bit of debugging code which tracks the start and > ends of each of these operations and visualizes them, and this is what I > noticed: > http://www.sethwillits.com/temp/upshot/upshot_yJutoKqY.png > > At very regular intervals everything takes longer. > > First I thought it maybe didn't like my semi-async op, so I made it truly > async, and it behaved exactly the same. To make a long story short, I looked > at this a few different ways in Instruments, and have confirmed that what's > actually happening is *every thread is blocked* for those 30-50ms, and then > it just wakes up and everything continues. The threads are literally all in > "Blocked" states. > > > I can't figure out *why* everything is blocked. I can't figure out why simply > making the NSOperation asynchronous would have this crazy effect. It's 100% > reproducible. > > For what it's worth, this one particular operation is doing some Metal > rendering, and that operation is blocked during a call to > -waitUntilCompleted. Which yes, sound suspicious, but is exactly what's > happening in the very-explicitly-synchronous version of the operation, and it > takes 10x less time. I am pretty certain this has nothing to do with the > Metal rendering itself, and has more to do with something confusing the > dispatch manager and every thread is being blocked. > > > Can anyone think of what I should look for to figure out *why* they're > blocked? Looking at the system calls in the Instruments trace timeline just > isn't telling *me* anything. > > > -- > Seth Willits > > > > > _______________________________________________ > > 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/zav%40mac.com > > This email sent to z...@mac.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
