September 6th, 2017

@owensd Thanks for updating.

3:27 PM, Sep 6th, 2017 via Tweetbot for Mac in reply to owensd

@daringfireball At this rate I’m expecting some Kubrick news by the end of the week.

3:16 PM, Sep 6th, 2017 via Tweetbot for Mac

@jckarter @pathofshrines Awesome, thanks.

3:12 PM, Sep 6th, 2017 via Tweetbot for Mac in reply to jckarter

@jckarter Because KVO checks are relaxed or because addresses of ivars are handled differently?

3:09 PM, Sep 6th, 2017 via Tweetbot for Mac in reply to jckarter

@jckarter @owensd Any way to give it a hint, given that it already knows it’s an Array<Int>?

2:47 PM, Sep 6th, 2017 via Tweetbot for Mac in reply to jckarter

@jckarter @owensd Yeah, I would have expected it to inline access to start index, etc., instead of calling through a witness table.

2:46 PM, Sep 6th, 2017 via Tweetbot for Mac in reply to jckarter

@jckarter @owensd Interesting…although that doesn’t seem to be what’s slowing this down.

2:40 PM, Sep 6th, 2017 via Tweetbot for Mac in reply to jckarter

@owensd Your code seems too simple to be wrong. A quick look in Instruments seems to show a lot of protocol overhead…

1:52 PM, Sep 6th, 2017 via Tweetbot for Mac in reply to owensd

@owensd Reallocating seems like a good guess. Why would you need a lot of ARC for Ints?

1:32 PM, Sep 6th, 2017 via Tweetbot for Mac in reply to owensd

@rowanxmas @owensd Pretty sure Swift does’t do that.

1:31 PM, Sep 6th, 2017 via Tweetbot for Mac in reply to rowanxmas

@owensd LL is not that surprising; I assume there’s ref-counting overhead. But two orders of magnitude slower for an array of Int?

1:29 PM, Sep 6th, 2017 via Tweetbot for Mac in reply to owensd

@owensd Wow, I wonder why the Swift numbers are so bad.

1:26 PM, Sep 6th, 2017 via Tweetbot for Mac in reply to owensd

@stuwillis Yes, still using for archives of projects and OS installations.

9:30 AM, Sep 6th, 2017 via Tweetbot for Mac in reply to stuwillis