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