[swift-corelibs-dev] IndexPath performance

[Stephan Tolksdorf]

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 <st at 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.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/7e197a3e/attachment.html>