[swift-evolution] [Review] SE-0052: Change IteratorType post-nil guarantee

[Patrick Pijnappel]

>
> 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 at 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 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/20160503/749064b2/attachment.html>