NSProgress Shortcomings and CSProgress
Unfortunately, the performance of NSProgress is simply terrible. While performance is not a major concern for many Cocoa classes, the purpose of NSProgress—tracking progress for operations that take a long time—naturally lends itself to being used in performance-critical code.
[…]
Furthermore, there’s no atomic way to increment the change count. To do so, one first has to get the current completedUnitCount, then add something to it, and then finally send that back to completedUnitCount’s setter, resulting in the lock being taken twice for one operation.
[…]
All of NSProgress’s reporting is done via KVO. That’s slick, right? You can just bind your UI elements, like NSProgressIndicator, directly to its fractionCompleted property and set it up with no glue code. Right? Well, no, because most classes in the UI layer need to be accessed on the main thread only, and NSProgress sends all its KVO notifications on the current thread. Hrm.
[…]
So instead of the main benefit of KVO—being able to bind UI elements to the model without glue code—we have more and much weirder glue code than we’d see in a typical blocks-based approach.
Overall, it seems like a terrific idea, but it’s unnecessarily difficult to use it well. His solution is a complete reimplementation, CSProgress, which bridges to NSProgress.
