<div dir="ltr">The following slight modification of the extension, however, makes test(strings) run as fast as test(caseSwappedStrings) (ie 0.07 seconds):<div><br><div><div>extension String {</div><div>    func componentsSeparatedByNewLineCharacter() -&gt; [String] {</div><div>        var lines = [String]()</div><div>        var currStr = String.UnicodeScalarView()</div><div>        let newLineUCS = UnicodeScalar(&quot;\n&quot;)</div><div>        for ucs in self.unicodeScalars {</div><div>            switch ucs {</div><div>            case newLineUCS: lines.append(String(currStr) + &quot; &quot;); currStr.removeAll()</div><div>            default: currStr.append(ucs)</div><div>            }</div><div>        }</div><div>        return lines</div><div>    }</div><div>}</div></div><div><br></div><div>Note that the only change is that a space is added to the string there ( + &quot; &quot; ).</div><div><br></div><div>So I guess that for some reason adding that space sets the String&#39;s isASCII bit ... But the strange thing is that if I try to remove the space, and no matter how I do that, the test(strings)-test goes back to being 2.3 seconds again (instead of 0.07 seconds).</div><div><br></div><div>It&#39;s almost as if there is a cached version of the original String (one that has its isASCII bit cleared) that is being reused as soon as I modify it in a way that makes it be the same as it was originally.</div><div>If so, I&#39;m guessing that it is the String.init(contentsOfFile: path) that is to blame (it&#39;s making an NSString-backed String with its isASCII bit cleared), because I&#39;m unable to reproduce the slow (now 2.3 seconds) behavior without loading from disk.</div><div><br></div></div><div>/Jens</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 2, 2016 at 10:02 PM, Jens Persson <span dir="ltr">&lt;<a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Interesting, thanks!<div>I tried using this extension</div><div><div>extension String {</div><div>    func componentsSeparatedByNewLineCharacter() -&gt; [String] {</div><div>        var lines = [String]()</div><div>        var currStr = String.UnicodeScalarView()</div><div>        let newLineUCS = UnicodeScalar(&quot;\n&quot;)</div><div>        for ucs in self.unicodeScalars {</div><div>            switch ucs {</div><div>            case newLineUCS: lines.append(String(currStr)); currStr.removeAll()</div><div>            default: currStr.append(ucs)</div><div>            }</div><div>        }</div><div>        return lines</div><div>    }</div><div>}</div></div><div>instead of componentsSeparatedByString(&quot;\n&quot;)</div><div><br></div><div>This made the slow non-caseSwapped test(strings) run in 2.3 seconds instead of the previous 9.5 seconds, but that is still relatively slow compared to the 0.066 seconds of the test(caseSwappedStrings).</div><div><br></div><div>Is there a way to make sure a String in Swift has the isASCII bit set (provided the original string contains only ASCII of course)?</div><span class="HOEnZb"><font color="#888888"><div><div><br></div><div>/Jens</div></div><div><br></div></font></span></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Wed, Mar 2, 2016 at 7:24 PM, Daniel Duan via swift-dev <span dir="ltr">&lt;<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Arnold Schwaighofer via swift-dev &lt;swift-dev &lt;at&gt; <a href="http://swift.org" rel="noreferrer" target="_blank">swift.org</a>&gt; writes:<br>
<br>
&gt;<br>
&gt; That is the difference between a “String” type instance that can use the<br>
&gt; ascii fast path and NSString backed “String” type instances.<br>
&gt;<br>
<br>
</span>This makes total sense now :) I was very mystified by this issue and thought<br>
it&#39;s a weird bias in the hashing function at some point.<br>
<br>
Thanks for the insight Arnold.<br>
<div><div>_______________________________________________<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="">-- <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>
</span></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>