> > However, if there really is a 25% speedup on UTF-8 decoding for ASCII > input, that's a pretty significant point in favor of the change. I saw the > gist that was used to come up with this 25% number. But I do have to ask, > does the 25% increase still hold when talking about String.UTF8View, or is > that significant speedup only shown when using the UTF8 type to transcode? > And similarly, what's the effect on performance for non-ASCII input?
The mentioned results are for decoding, i.e. UTF8 in, while UTF8View is about transcoding/encoding, i.e. UTF8 out. But any thin wrapper around UTF8 decode (e.g. String(cString:)) should see basically the same speed-ups. I haven't tested UTF16 decode, but the code path for all non-surrogates is very similar to UTF8's ASCII decode and should the same similar gains – which should translate directly into gains for e.g. iterating over a UnicodeScalarView. As for non-ascii input, the extra branch is a smaller slice of the total, making the speed-up ~10%. Similarly, do we have any numbers for the effect on performance for a > custom Iterator that now has to track state which it otherwise wouldn't? > TakeWhileIterator would be a good candidate for testing, except it hasn't > been implemented yet (though it shouldn't be hard to whip up a sample > implementation for that). In the common cases I tested so far (where post-nil isn't used) the branch is optimized away, but probably you could thwart the optimizer somehow. The performance hit then would be likely be (very) roughly speaking the 1 over the total number of branches in the loop. On Tue, May 3, 2016 at 8:24 AM, Kevin Ballard via swift-evolution < swift-evolution@swift.org> wrote: > On Thu, Apr 28, 2016, at 11:12 AM, Chris Lattner via swift-evolution wrote: > > Hello Swift community, > > > > The review of "SE-0052: Change IteratorType post-nil guarantee" begins > now and runs through May 3. The proposal is available here: > > > > > https://github.com/apple/swift-evolution/blob/master/proposals/0052-iterator-post-nil-guarantee.md > > > > Reviews are an important part of the Swift evolution process. All > reviews should be sent to the swift-evolution mailing list at > > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > or, if you would like to keep your feedback private, directly to the > review manager. > > > > What goes into a review? > > > > The goal of the review process is to improve the proposal under review > through constructive criticism and, eventually, determine the direction of > Swift. When writing your review, here are some questions you might want to > answer in your review: > > > > * What is your evaluation of the proposal? > > I was originally strongly -1 on this (as can be seen from my previous > messages on this ML about this topic), both for the reasons that Gwendal > Roué wrote as well as my belief that the vast majority of users never even > write code that hits this case at all and my own experience in that it's > actually more common for me as an author of a custom Iterator to have to > worry about meeting this guarantee than it is for anyone using my Iterator > to rely on the behavior. > > However, if there really is a 25% speedup on UTF-8 decoding for ASCII > input, that's a pretty significant point in favor of the change. I saw the > gist that was used to come up with this 25% number. But I do have to ask, > does the 25% increase still hold when talking about String.UTF8View, or is > that significant speedup only shown when using the UTF8 type to transcode? > And similarly, what's the effect on performance for non-ASCII input? > > Similarly, do we have any numbers for the effect on performance for a > custom Iterator that now has to track state which it otherwise wouldn't? > TakeWhileIterator would be a good candidate for testing, except it hasn't > been implemented yet (though it shouldn't be hard to whip up a sample > implementation for that). > > > * Is the problem being addressed significant enough to warrant a > change to Swift? > > Yes. The current defined behavior is pretty much the worst of all options > since it encourages library authors to deliberately crash, and yet no > stdlib type actually does crash, so it makes it easy to write code that > works for stdlib iterators but will fail when given a third-party iterator. > > > * Does this proposal fit well with the feel and direction of Swift? > > Yes. > > > * If you have you used other languages or libraries with a similar > feature, how do you feel that this proposal compares to those? > > Rust's equivalent Iterator type is defined such that after a previous call > to next() has returned None, Iterators are allowed to return either None or > Some(Item) from subsequent calls to next() (but shouldn't crash). And Rust > has a FuseIterator (and a corresponding .fuse() method). This matches the > first alternative in the proposal. And with this approach, it's true that > it's extremely rare for people to call .fuse() (but this just demonstrates > that very few people write code where post-nil behavior matters), but it > does simplify many Iterator implementations, and AFAIK nobody's complained > about this behavior. > > > * How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? > > An in-depth study. > > -Kevin Ballard > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution