<div dir="ltr">Oh, I'm sorry, Tony, I was too hasty and mistook your last name for your first name :-(<div><br></div><div>- Stephan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 2 August 2016 at 12:04, Stephan Tolksdorf <span dir="ltr"><<a href="mailto:st@quanttec.com" target="_blank">st@quanttec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Parker,<div><br></div><div>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.</div><div><br></div><div>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?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- Stephan</div></font></span><div><div class="h5"><div><br></div><div class="gmail_extra"><div class="gmail_quote">On 2 August 2016 at 11:09, Tony Parker <span dir="ltr"><<a href="mailto:anthony.parker@apple.com" target="_blank">anthony.parker@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Stephan,<br>
<br>
Do you have some benchmarks that you could share? That would help us focus performance work in the right area.<br>
<br>
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.<br>
<br>
- Tony<br>
<div><div><br>
> On Aug 1, 2016, at 11:44 PM, Stephan Tolksdorf via swift-corelibs-dev <<a href="mailto:swift-corelibs-dev@swift.org" target="_blank">swift-corelibs-dev@swift.org</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> 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?<br>
><br>
> - Stephan<br>
</div></div>> _______________________________________________<br>
> swift-corelibs-dev mailing list<br>
> <a href="mailto:swift-corelibs-dev@swift.org" target="_blank">swift-corelibs-dev@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-corelibs-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev</a><br>
<br>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>