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 refcounting? It seems to me that this type is mainly used in ObjC interop code. In native Swift code I would always try to avoid using a dynamically sized, heap allocated array as a data structure index. If NSIndexPath can't be bridged to a native Swift type without introducing additional overhead, then maybe it shouldn't be bridged at all? - Stephan On 2 August 2016 at 11:09, Tony Parker <anthony.par...@apple.com> wrote: > Hi Stephan, > > Do you have some benchmarks that you could share? That would help us focus > performance work in the right area. > > I know that 2-item IndexPaths are super common with UIKit collection view > and friends, so we may just want to special case those. Unfortunately, > NSIndexPath is not abstract, so subclassing it in the same way that we do > for a few of the other bridged types (to use native Swift refcounting) is > not easy. On the other hand, the ObjC implementation does use tagged > pointers, so some NSIndexPaths are really cheap to create. > > - Tony > > > On Aug 1, 2016, at 11:44 PM, Stephan Tolksdorf via swift-corelibs-dev < > swift-corelibs-dev@swift.org> wrote: > > > > Hi, > > > > IndexPath is currently implemented using an [Int] array that is bridged > to an NSIndexPath only on demand. Since IndexPath values are primarily used > together with Objective-C APIs, wouldn't it be better to implement > IndexPath directly as an NSIndexPath wrapper, in order to avoid the > overhead of temporary array instances? > > > > - Stephan > > _______________________________________________ > > swift-corelibs-dev mailing list > > swift-corelibs-dev@swift.org > > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > >
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev