On Aug 2, 2016, at 6:04 PM, Stephan Tolksdorf <firstname.lastname@example.org> wrote:
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
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?
I do think it is likely we could figure out some improvements here, but
I’d like to start with a concrete test (and something that is
representative of real world use cases). If it’s possible to extract
something out of what you’ve already done, that would be really helpful. We
can also file a bug on bugs.swift.org as a call for help designing a
better perf test suite (we need this for all of the types, frankly).
Once we know we’re measuring the right thing, there are all kinds of
interesting things we can do. If (when?) we have ABI stability in Swift 4,
we may be able to also change the ObjC Foundation.framework to better
cooperate with the Swift side, as we’ll be able to tie the current overlay
code to a specific OS instead of having to run back several releases.
On 2 August 2016 at 11:09, Tony Parker <email@example.com> wrote:
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.
> On Aug 1, 2016, at 11:44 PM, Stephan Tolksdorf via swift-corelibs-dev < >> firstname.lastname@example.org> wrote:
> 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