I have created one testing app for running deep counter loop. I run the loop function in background thread using performSelectorInBackground and also NSOperation subclass separately.
I am also using performSelectorOnMainThread to notify main thread within backgroundthread method and [NSNotificationCenter defaultCenter] postNotificationName within NSOperation subclass to notify main thread for updating UI.
Initially both the implementation giving me same result and i am able to update UI without having any problem. The only difference I found is the Thread count between two implementations.
The performSelectorInBackground implementation created one thread and got terminated after loop finished and my app thread count again goes to 1.
The NSOperation subclass implementation created two new threads and keep exists in the application and i can see 3 threads after loop got finished in main() function.
So, my question is why two threads created by NSOperation and why it didn’t get terminated just like the first background thread implementation?
I am little bit confuse and unable to decide which implementation is best in-terms of performance and memory management.
It’s likely the operation queue is keeping threads alive, waiting for new operations to appear.
You have to remember that the operation queue is designed to work efficiently with many operations, so creating and destroying threads for each operation is going to hurt performance. So what you are seeing is probably just the way the queue is designed to work by keeping a pool of threads alive.
Basically, as long as you are using the operation queue properly and according to the documentation I wouldn’t worry about it.