I can't reproduce this, even in -Onone:

swiftc -Onone x.swift -o /tmp/x && /tmp/x

Starting copy
Copy dur: 2.40206718444824e-05 s

Are you sure you didn't leave off the e-05 from the result? ;-)

Comment by Rick M (JIRA)

Copied-and-pasted directly from Xcode 8.3.2 (8E2002). Attached Playground file.
SlowArrayCopy.playground.zip

Running this in Playground is slow because Playground need to display the results.

let array2 = Array(array1) doesn't even force copying in the current stdlib implementation; array1 and array2 still share the buffer.

Comment by Rick M (JIRA)

I don't buy that this is slow because it needs to display results. That doesn't really make any sense. Can you explain why this would be the case?

If you want to more closely reporduce the situation I see running on our iOS device, you can take a slice of array1 when making the copy. That's the only difference. It didn't seem necessary for this example since performance is so bad with the example as given.

Rintaro's is the likeliest explanation. As he says, there is basically no computation required to "copy" or to slice an array.

You could definitely consider this an Xcode/playgrounds bug, but then I think you'd want to file a radar as that code is not part of the open source Swift project.

Comment by Rick M (JIRA)

So, this first showed up in code on an iOS app (both Simulator and device). I just tried to get a reproducible case in a Playground. But it's not a Playground bug. What else could it be?

rmann (JIRA User) I have no clue, sorry. I don't think the code you're running in your playground is what's slowing down your iOS app though. I suggest you reduce the app until you can isolate the problem.

Comment by Rick M (JIRA)

I can promise you it was this line of code:

thing = Array(self.dataBuffer![0 ..< bigSize])

But that line of code is a very different matter. Copying a slice of an array into an Array is O(N), because the Array has a 1-word representation (pointer-to-buffer) and can't represent a slice of some other buffer.

Comment by Rick M (JIRA)

So, in my comment a couple hours ago I said "If you want to more closely reporduce the situation I see running on our iOS device, you can take a slice of array1 when making the copy." The response from you was "there is basically no computation required to "copy" or to slice an array," so I assumed you were saying it wouldn't be making the copy.

Nevertheless, it seems to be a very slow copy. I fully expect it to be O(N), but two seconds to copy a megabyte? That sounds like an unoptimized loop, rather than a call to memcpy() (or similar).

— So, in my comment a couple hours ago I said "If you want to more closely reporduce the situation I see running on our iOS device, you can take a slice of array1 when making the copy." The response from you was "there is basically no computation required to "copy" or to slice an array," so I assumed you were saying it wouldn't be making the copy.

Sorry, lots going on here; subtle hints can get lost in the noise.

— Nevertheless, it seems to be a very slow copy. I fully expect it to be O(N), but two seconds to copy a megabyte? That sounds like an unoptimized loop, rather than a call to memcpy() (or similar).

That does sound very slow. Is this a debug or release build?

Comment by Rick M (JIRA)

I do believe it was a debug build. Not sure what the Playground is doing.

That doesn't surprise me too much then. With this program:

import Foundation

func test() {
  let hugeSize = 1 * 1024 * 1024
  let array1 = [UInt8](repeating: 0, count: hugeSize)
  print("Starting copy")
  let startTime = CFAbsoluteTimeGetCurrent()
  let array2 = Array(array1[1..<array1.endIndex])
  let endTime = CFAbsoluteTimeGetCurrent()
  let dur = endTime - startTime
  print("Copy dur: \(dur) s")
  if CommandLine.arguments.count == 1000 {  print(array2) }
}

test()

$ swiftc -Onone x.swift -o /tmp/x && time /tmp/x
Starting copy
Copy dur: 0.262063026428223 s

real    0m0.274s
user    0m0.256s
sys 0m0.004s
$ swiftc -O x.swift -o /tmp/x && time /tmp/x
Starting copy
Copy dur: 0.00106900930404663 s

real    0m0.012s
user    0m0.004s
sys 0m0.003s

If it's any consolation, when I use the current master branch of Swift in -Onone, I get:

Starting copy
Copy dur: 0.00223302841186523 s

real    0m0.014s
user    0m0.006s
sys 0m0.004s