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 <s...@quanttec.com> wrote: > 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
