[swift-evolution] Open Issues Affecting Standard Library API Stability

[Karl]

> On 7 Jul 2016, at 03:15, Karl <raziel.im+swift-evo at gmail.com> wrote:
> 
> 
>> On 7 Jul 2016, at 02:06, Dmitri Gribenko <gribozavr at gmail.com <mailto:gribozavr at gmail.com>> wrote:
>> 
>> On Wed, Jul 6, 2016 at 4:21 AM, Karl <razielim at gmail.com <mailto:razielim at gmail.com>> wrote:
>>> I had a PR open for this which added a Collection specialisation, but you
>>> said this could be handled in a more general way which allows for more
>>> optimised mutations. I’m curious how this would work; how does
>>> `RangeReplaceableCollection.replaceSubrange<S:Sequence>(range:, with: S)`
>>> call a more optimised implementation if S also conforms to Collection, if
>>> not by adding a specialisation?
>> 
>> The RRC can call into S.someCustomizationPoint(), which will
>> initialize a region of memory in the most efficient way possible,
>> since it has complete knowledge about the memory layout of S.
>> 
>> Dmitri
>> 
>> -- 
>> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
>> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com <mailto:gribozavr at gmail.com>>*/
> 
> Sorry, it’s been a little while since I looked at it (https://github.com/apple/swift/pull/3067 <https://github.com/apple/swift/pull/3067>). Actually, the issue is with the append() function specifically - it only has a Sequence specialisation. That’s the point; we were losing type information and not calling the more optimised replaceSubrange — which is exactly the specialisation point you are talking about, Dmitry (I think everything funnels down in to replaceSubrange).
> 
> I must have misunderstood what you were saying at the time. I’ll have to test, but I think it’s still an issue. I thought there was some more general work on RRC planned, so when I saw the bullet I thought maybe that was it.
> 
> @Dave:
> 
> I was trying to initialise a String.CharacterView - depending on whether I initialised it with another CharacterView, or created it empty and appended the other CharacterView, I would get huge performance differences, as the other CharacterView would get split up and a new Character created and appended for every character in the string (which had like 10,000 characters). It’s a subtle bug and a bit nasty when it hits you.
> 
> Karl

Ah no, my memory’s coming back - it wasn’t the overhead in the standard library that was the biggest problem, as much as the 10,000 calls to replaceSubrange with a single element being appended. We had to do some additional processing, and it was just killer doing it so many times.

Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160707/509f2097/attachment.html>