<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">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?</span></blockquote><div><br></div><div>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.</div><div><br></div><div>As for non-ascii input, the extra branch is a smaller slice of the total, making the speed-up ~10%.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">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).</span></blockquote><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 3, 2016 at 8:24 AM, Kevin Ballard via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Apr 28, 2016, at 11:12 AM, Chris Lattner via swift-evolution wrote:<br>
> Hello Swift community,<br>
><br>
> The review of "SE-0052: Change IteratorType post-nil guarantee" begins now and runs through May 3. The proposal is available here:<br>
><br>
> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0052-iterator-post-nil-guarantee.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0052-iterator-post-nil-guarantee.md</a><br>
><br>
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at<br>
><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> or, if you would like to keep your feedback private, directly to the review manager.<br>
><br>
> What goes into a review?<br>
><br>
> 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:<br>
><br>
> * What is your evaluation of the proposal?<br>
<br>
</span>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.<br>
<br>
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?<br>
<br>
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).<br>
<span class=""><br>
> * Is the problem being addressed significant enough to warrant a change to Swift?<br>
<br>
</span>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.<br>
<span class=""><br>
> * Does this proposal fit well with the feel and direction of Swift?<br>
<br>
</span>Yes.<br>
<span class=""><br>
> * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br>
<br>
</span>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.<br>
<span class=""><br>
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br>
<br>
</span>An in-depth study.<br>
<br>
-Kevin Ballard<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>