My app uses an NSOperationQueue
to cache thumbnail images in a background thread. On the iPad2 I can push the concurrent task count limit up to 5 or 6, but on s
I guess this needs a separate answer rather than a comment:
I wonder what does the number of cores means now that apple brought more asymmetric processing with A10 fusion? Do we have 2.2 cores or 4 cores? apple neglected to make activeProcessorCount float to account for it's fractal nature. note it was like so even before fusion cause they likely had thermal throttling back then. They need either fix overcomittal of nsoperationqueue or come up with a float equivalent for activeProcessorCount and deprecate the activeProcessorCount in its current form that is losing its utility in the face of recent hw advancements
So the faster the Moore's law falls into oblivion or receives a shiny new constant the more meaningless core counting becomes. Unless you are writing some sort of a Geek Bench 42, multicore score edition.
Living in the late 2016, to address the underlying issue you are facing rather than hacking through with max concurrent operation prop I assume you have adjusted the QoS for the NSOperationQueue to .Background?
Me thinks this is a cleaner way to solve your problem with modern ios sdk then counting 'em cores using miles of rope courtesy of albertamg
Also please take a look at NSProcessInfoThermalStateDidChangeNotification (macos) and NSProcessInfo.lowPowerModeEnabled (ios) (I guess an alternative to observing NSProcessInfoThermalStateDidChangeNotification is to KVo on activeProcessorCount new value)
if you start to account for those new realities, the magic constants adjustments for multiplying core count would get interesting very fast... and rot as the new hardware rolls out of cupertino.
And it will be just about as easy to get it right on the current zoo of Apple hw as to get socket-level networking working correctly: doable, but by select few in Cupetino with iSteve shadow looming over the shoulder checking quality ;-)