[swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

[Rod Brown]

I applaud the idea. I too find the (NS)Progress API to be very low quality. It seems a vestige of an earlier time when Cocoa was young and APIs that seem like they should be simple, just... aren't. I would love to see a much better API developed.

I'm curious how this idea of developing something from the ground up works with Apple's preferred idea of using Swift to bring Foundation forward.

-Rod

> On 18 Feb 2017, at 6:48 am, Charles Srstka via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Feb 17, 2017, at 1:42 PM, Charles Srstka via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> - Much better performance. In my testing, updating the completedUnitProperty, with something observing it, takes 1.04 seconds on my 2013 Retinabook, compared with NSProgress’s 52.91 seconds (58.53 seconds if an autorelease pool is used). This frees back-end code from the responsibility of being adulterated with what is effectively UI code in order to determine when the progress object should be updated.
> 
> This should have said “updating the completedUnitProperty one million times, with something observing it.” I eagerly await the implementation of our new forum, hopefully with an edit feature, with bated breath.
> 
> Charles
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170221/042f43fa/attachment.html>