<div dir="ltr">(Correction: 0.07 seconds, not 0.7 seconds.)</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 4, 2016 at 10:33 AM, Jens Persson <span dir="ltr"><<a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.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">Another thing I noticed is that making a Set<NSString> (rather than a Set<String>) is fast ...<div><br></div><div>That is (for those same particular strings) this is fast (0.7 s):</div><div>let setOfNSStrings = Set<NSString>(strings.map { $0 as NSString })<br></div><div><br></div><div>while this is slow (9.5 s):</div><div>let setOfNSStrings = Set<String>(strings)<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>/Jens</div><div><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 4, 2016 at 9:48 AM, Jens Persson <span dir="ltr"><<a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.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">Are you already tracking/looking into this in someway or should I file a bug?<span><font color="#888888"><div>/Jens</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 3, 2016 at 5:55 AM, Arnold <span dir="ltr"><<a href="mailto:aschwaighofer@apple.com" target="_blank">aschwaighofer@apple.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="auto"><div>Yes this does not explain what you are seeing. (I could repeat this on my end)</div><div><br></div><div>If you look at the two runs under instruments: one run with the slow strings file and one with the fast strings file (I tested with space appended to each line); you will notice that we spend a lot more time in the Set's find function doing NSString comparisons. The only explanation I have for this is hash collisions leading to more comparisons as we are probing non empty buckets. Why one of the files would trigger this and the other not makes no sense to me.</div><div>This will need looking at.</div><div><br>Sent from my iPhone</div><div><div><div><br>On Mar 2, 2016, at 6:43 PM, Jens Persson <<a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Just thought I should mention that I tried another thing:<div><br></div><div>Using my original example:</div><div><a href="http://sloppyfocus.com/slowSetFromParticularButSeeminglyNormalArrayOfStrings.html" target="_blank">http://sloppyfocus.com/slowSetFromParticularButSeeminglyNormalArrayOfStrings.html</a><br></div><div>Keeping the code as it is but adding a space to the end of every line in the actual text file (strings.txt).</div><div><br><div><div>This actually makes the slow test(strings) run almost as fast as the fast test(caseSwappedStrings), 0.09 seconds, so about a hundred times faster just because the text file has an extra space at the end of each line.</div><div><br></div><div>I just can't see how Arnold Schwaighofer's explanation explains that ... An added space character at the end of each line of that text file is just one more ASCII character, how can that make test(strings) so much faster?<br></div><div><div><div><br></div><div>And other operations on the text file makes the slow test faster too, like eg:</div><div>Inserting a space as the first char of each line, 0.9 seconds.</div><div>Removing all spaces, 0.9 seconds.</div><div>Replacing all spaces with "-" (replacing the dashes back to spaces made it slow again), 0.9 seconds.</div></div><div>Replacing all "a" with "*", 0.9 seconds.</div><div>Swapping case (now in the actual file instead of programmatically), 2.3 seconds.</div><div>(I only tried operations that kept the resulting strings unique and their characters plain ASCII.)</div><div><br></div><div>/Jens</div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 2, 2016 at 6:28 PM, Arnold Schwaighofer <span dir="ltr"><<a href="mailto:aschwaighofer@apple.com" target="_blank">aschwaighofer@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That is the difference between a “String” type instance that can use the ascii fast path and NSString backed “String” type instances.<br>
<br>
When the code translates the string (the map function that calls upper case) it becomes a natively backed “String” that isASCII.<br>
<br>
// The strings in strings.txt are not strange in any way, they all match ^[a-zA-Z ]+$.<br>
<br>
Set the isASCII bit and things are blazing fast.<br>
<br>
The other path is that componentsSeparatedByString(separator: String) -> [String] returns an “[String]” where every “String” is backed by “NSString”. When it comes to do comparison we call a NSString function on the NSString and this is where the difference in performance comes from.<br>
<div><div><br>
<br>
<br>
<br>
> On Mar 2, 2016, at 12:15 AM, Jens Persson via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:<br>
><br>
> I guess it would be possible to isolate the problem by analyzing my example, and thereby making it possible to write a smaller benchmark which doesn't need that big textfile. I didn't manage to do that however, hence my question about the problem here.<br>
> /Jens<br>
><br>
> On Wed, Mar 2, 2016 at 9:11 AM, Jens Persson <<a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a>> wrote:<br>
> Thanks, but I'll have to invite anyone with more time and experience to do that.<br>
><br>
> One (of many) thing(s) I wouldn't know how include/handle is the 1.3 MB text file for the particular arrayOfStrings that makes Set(arrayOfStrings) slow. It seems a bit unnecessary/bloating to put it in the code base.<br>
><br>
> /Jens<br>
><br>
> On Tue, Mar 1, 2016 at 11:58 PM, Nadav Rotem <<a href="mailto:nrotem@apple.com" target="_blank">nrotem@apple.com</a>> wrote:<br>
> Hi Jens,<br>
><br>
> Thanks for reporting this issue. I don’t know what’s going on but we’ll take a look.<br>
><br>
> I think it would be great if you could add this program as a benchmark under swift/benchmarks/. This will allow us to track the performance of this test and ensure that we don’t regress.<br>
><br>
> Thanks,<br>
> Nadav<br>
><br>
>> On Mar 1, 2016, at 5:01 AM, Jens Persson via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:<br>
>><br>
>> For some particular arrays of strings, creating a Set<String>(arrayOfStrings) takes about 100 to 200 times longer than for other very similar arrays of strings (equally many unique simple [a-zA-Z ]+ strings).<br>
>><br>
>> I've put together a tiny program to demonstrate the problem here:<br>
>> <a href="http://sloppyfocus.com/slowSetFromParticularButSeeminglyNormalArrayOfStrings.html" rel="noreferrer" target="_blank">http://sloppyfocus.com/slowSetFromParticularButSeeminglyNormalArrayOfStrings.html</a><br>
>><br>
>> Is this due to a bug / performance problem in Set or can it be explained (and solved) in some way?<br>
>><br>
>> /Jens<br>
>><br>
>> _______________________________________________<br>
>> swift-dev mailing list<br>
>> <a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden<br>
> <a href="http://www.bitcycle.com/" rel="noreferrer" target="_blank">http://www.bitcycle.com/</a><br>
> Phone: +46-73-753 24 62<br>
> E-mail: <a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a><br>
><br>
><br>
><br>
><br>
> --<br>
> bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden<br>
> <a href="http://www.bitcycle.com/" rel="noreferrer" target="_blank">http://www.bitcycle.com/</a><br>
> Phone: +46-73-753 24 62<br>
> E-mail: <a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a><br>
><br>
> _______________________________________________<br>
> swift-dev mailing list<br>
> <a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-dev</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden<br><a href="http://www.bitcycle.com/" target="_blank">http://www.bitcycle.com/</a><br>Phone: +46-73-753 24 62<br>E-mail: <a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a><br><br></div>
</div>
</div></blockquote></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden<br><a href="http://www.bitcycle.com/" target="_blank">http://www.bitcycle.com/</a><br>Phone: +46-73-753 24 62<br>E-mail: <a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a><br><br></div>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden<br><a href="http://www.bitcycle.com/" target="_blank">http://www.bitcycle.com/</a><br>Phone: +46-73-753 24 62<br>E-mail: <a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a><br><br></div>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden<br><a href="http://www.bitcycle.com/" target="_blank">http://www.bitcycle.com/</a><br>Phone: +46-73-753 24 62<br>E-mail: <a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a><br><br></div>
</div>