Re: [swift-corelibs-dev] IndexPath performance

FWIW, if you agree that this approach is reasonable, I would be willing to write the patch for it. -Kevin Ballard On Tue, Aug 2, 2016, at 05:46 PM, Kevin Ballard wrote: > I agree with Stephan, NSIndexPath performance is important and we > should avoid the overhead of allocating/freeing an array

Re: [swift-corelibs-dev] IndexPath performance

I agree with Stephan, NSIndexPath performance is important and we should avoid the overhead of allocating/freeing an array for the common case. Instead of just always wrapping NSIndexPath, maybe we should just switch the internal representation to something like enum Indices { case one(Int)

[swift-corelibs-dev] Query on init methods in Data.swift

Hi I was looking at Data.swift and noticed that 2 of the init methods were different in corelibs-foundation v swift stdlib https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/Data.swift has public init?(capacity: Int) public init?(count: Int)

Re: [swift-corelibs-dev] IndexPath performance

Oh, I'm sorry, Tony, I was too hasty and mistook your last name for your first name :-( - Stephan On 2 August 2016 at 12:04, Stephan Tolksdorf wrote: > Hi Parker, > > I noticed the IndexPath overhead when I investigated why a Swift 3 > implementation of

Re: [swift-corelibs-dev] IndexPath performance

Hi Parker, I noticed the IndexPath overhead when I investigated why a Swift 3 implementation of UICollectionViewLayout.layoutAttributesForElementsInRect spent more time in malloc, free and related methods, but I don't have a benchmark. Is it important that IndexPath uses native Swift

Re: [swift-corelibs-dev] [SR-1608]

Hi David, Thanks for helping! Can you check out some of our current open PRs to make sure your work isn’t overlapping? We’ve had some contributions in this area recently that we still need to finish merging. - Tony > On Jul 29, 2016, at 11:28 PM, David Liu via swift-corelibs-dev >