[swift-evolution] Improvement proposal: change overflow behavior in successor()/predecessor() methods for Int types

[Haravikk]

> On 7 Apr 2016, at 18:54, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Thu, Apr 7, 2016 at 12:20 AM, Vladimir.S via swift-evolution
> <swift-evolution at swift.org> wrote:
>> But. .successor() .predecessor() methods for Int values do not follow these
>> rules for overflow situations. I.e. :
>> let i : Int8 = Int8.max
>> let k : Int8 = i.successor()
>> - is OK for current Swift compiler. We have i==127 and k==-128, no run-time
>> error.
> 
> This was done for performance reasons.  Array's indices are Ints, and
> adding an overflow check here was causing significant performance
> issues when iterating over arrays.

Sorry to bump this after it’s been idle for a little while, but I was thinking about this again recently and I can’t come up with a test that verifies a meaningful performance difference. I just threw the following into a playground:

import Foundation

do {
    let startTime = NSDate().timeIntervalSince1970
    var i = 0
    while i < 1000000 { i = i &+ 1 }
    let elapsed = NSDate().timeIntervalSince1970 - startTime
}

do {
    let startTime = NSDate().timeIntervalSince1970
    var i = 0
    while i < 1000000 { i = i + 1 }
    let elapsed = NSDate().timeIntervalSince1970 - startTime
}

My results come out with no discernible performance difference; I suspect that this a side-effect of the iteration and storing overhead, but it seems to me that this is the kind of minimum boilerplate you are going to have anyway if you’re using .successor(). I know the issue is specifically with array iteration, but I don’t believe I actually need an array involved to demonstrate this, in fact the extra overhead would make the difference even less noticeable.

Is there a test that can demonstrate a more extreme difference? Even so, if the issue is with array iteration then it seems that the best place to fix that is in the array’s generator, rather than using the more generic IndexingGenerator that has no awareness of the underlying index type.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160423/52b38679/attachment.html>