<div dir="ltr">There&#39;s no reason why writing data to disk should be slower in Swift than in C/C++.<div><br></div><div>(For the name and location properties, I assume you want to save Strings, a sequence of characters or something rather than just the value of the UnsafePointer&lt;UInt8&gt;.)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 1, 2016 at 11:22 PM, Игорь Никитин <span dir="ltr">&lt;<a href="mailto:devnikor@icloud.com" target="_blank">devnikor@icloud.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="auto"><div>I got it. Thanks for your tips!</div><div><br>2 окт. 2016 г., в 0:13, Jens Persson &lt;<a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a>&gt; написал(а):<br><br></div><div><div class="h5"><blockquote type="cite"><div><div dir="ltr">You could write some examples in both C and Swift in order to gain experience in how to write your Swift code so that it will (probably) run as fast as (or faster than) your corresponding C code.<div><br></div><div>I&#39;ve done this for a number of different performance critical things and it is often possible to get the Swift version as fast as the C version.</div><div><br></div><div>(If you find something that is not possible (or unnecessarily cumbersome) to write as fast in Swift as in C, you could probably file a bug/improvement on <a href="http://bugs.swift.org" target="_blank">bugs.swift.org</a>. I did this some time ago when I noticed that Swift&#39;s optimizer missed an opportunity to unroll loops in a certain situation and it turned out that a fix/optimizer-improvement was already on its way.)</div><div><br></div><div>You must of course profile/microbenchmark your code in some meaningful way, setting all relevant compiler flags for both C and Swift, preventing dead code elimination, measuring average or perhaps median times of lots of tests, making sure what should and shouldn&#39;t be statically knowable, etc.<br></div><div><br></div><div>In Swift you probably want -O -whole-module-optimization, and (rarely) you might want/need to disable safety checks.</div><div><br></div><div>/Jens</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 1, 2016 at 10:33 PM, Daniel Dunbar via swift-users <span dir="ltr">&lt;<a href="mailto:swift-users@swift.org" target="_blank">swift-users@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">Yes, it is possible. Exactly how much use of Unsafe style idioms and other performance-focused &quot;workarounds&quot; it requires depends a lot on the code in question. Can you say more about your problem area?<br>
<br>
 - Daniel<br>
<div><div><br>
&gt; On Oct 1, 2016, at 1:30 PM, Игорь Никитин via swift-users &lt;<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Hello!<br>
&gt; Is it possible for Swift to be as fast as C when writing performance critical code? Of course if using C Standard Library for instead of Foundation (and so on) and getting rid of dynamic dispatch and reference types.<br>
&gt; Or I need just to use C?<br>
&gt; ______________________________<wbr>_________________<br>
&gt; swift-users mailing list<br>
&gt; <a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br>
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-users</a><br>
<br>
______________________________<wbr>_________________<br>
swift-users mailing list<br>
<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-users</a><br>
</div></div></blockquote></div><br></div>
</div></blockquote></div></div></div></blockquote></div><br></div>