[swift-corelibs-dev] IndexPath performance

[Stephan Tolksdorf]

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.parker at 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 at 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 at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160802/762a40f1/attachment.html>