> On 7 Jul 2016, at 03:15, Karl <[email protected]> wrote:
>
>
>> On 7 Jul 2016, at 02:06, Dmitri Gribenko <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> On Wed, Jul 6, 2016 at 4:21 AM, Karl <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>>*/
>
> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
