<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">With that tweak, the zip+stride approach actually clocks in faster than the C-style for. Yes, you read that right: <i class="">faster</i>.</div></div></div></blockquote><br class=""></div><div class="">One problem: zip+stride suffers tremendously at -Onone. One test looked like this (normalized elapsed time; smaller is better)</div></div></div></blockquote><br class=""></div><div><div class="">Do we really care about -Onone performance? Doesn’t that flag specifically mean “I don’t care about performance?”</div><div class=""><br class=""></div><div class="">All kinds of Swift code incurs massive performance penalties with -Onone, but the core team hasn’t let that hold back the language. See the “results” section here, for example: <a href="http://www.jessesquires.com/apples-to-apples-part-two/" class="">http://www.jessesquires.com/apples-to-apples-part-two/</a></div><div class=""><br class=""></div><div class="">IMO, we should design languages around performance concerns only when a construct has an _inherent_ performance limitation. I’d say these timings results show pretty clearly that no such inherent limitation exists here.</div><div class=""><br class=""></div><div class="">Cheers, P</div><div class=""><br class=""></div></div><br class=""></body></html>