Swiftのfor inとmapやreduceの速度を比べてみる
きしかわせんせいからfor inとmapなどを比べてみるというリクエストをいただいたので、早速やってみたいと思います。 ちなみにきしかわせんせい曰くSwift2や3ではfor inの方が速かったそうです。 今回の環境はSwift version 4.0.3とiPhone Xの組み合わせです。 for inとmapを比べてみます。 コードは以下のようになっています。testメソッドのクロージャ引数内の実行時間を出力します。Rangeから配列へ射影しますが、そのままコピーしているだけです。できるだけ簡素な実装にしています。 まずは-Ononeで最適化無しです。 Execution time - for in: 0.084015965461731 Execution time - map: 2.84733605384827for inが圧倒的です。 次に-O -whole-module-opti
#cmdevio2016 (レポート: B-3) Swiftで書かれたコードのパフォーマンス・チューニング | DevelopersIO
本記事ではDevelopers.IO 2016 セッションB-3でRealm 岸川克己氏に発表いただきましたSwiftで書かれたコードのパフォーマンス・チューニングのレポートをお届けします。 はじめに 今回しない最適化の話 アルゴリズム メモリ 言語機能をつかった最適化の話をします。 自己紹介 Realmで働いています。 是非この後もRealmについて聞きに来てください。 SQLiteより高速で使いやすいです。 最適化の前に 早すぎる最適化は諸悪の根源である（Knuth先生: Art of computer Programming の著者） 最適化の前に計測する 可読性とのトレードオフ UITableViewとかでキャッシュをクリアするとかもあるある ソフトウェア 80 / 20 ルール （20％の実行コードが80%の実行時間を占めている） ありとあらゆるところを最適化しても効果は得られな
Swift実行ファイルを逆アセンブルして、最適化具合を正確に把握する方法 - Qiita
SwiftはOptimization Levelによって顕著にパフォーマンスに差が出ます。 参考: Apples to apples, Part II · Jesse Squires また、Dynamic Dispatchでの呼び出しもオーバーヘッドになります。 参考: Swiftのfinal・private・Whole Module Optimizationを理解しDynamic Dispatchを減らして、パフォーマンスを向上する - Qiita ドキュメントなど読み解けば「どういう記述をすればどうコンパイルされるか」は大体予測付きますが、やはり実際にその予測通りになっているかは確認しておきたい時があります。 特にロガーなどグローバルに呼び出されるものの場合、そういう確認大事だと思っています。 (この記事もロガーの検証が元々の目的で、そのために調べてまとめています。ロガーについても記事
Swift Performance in Xcode 6.3 Beta
Back in December we ported a few of our Geekbench workloads to Swift and compared their performance to the C++ implementations. With last week's announcement of a beta release of Xcode 6.3 we thought it would be a good time to revisit those results. In this post we find out whether the performance improvements in Xcode 6.3 Beta provide any speedup for our Swift workloads. The following table shows
Swift v1.2 Performance – owensd.io
In a series of posts I wrote a few weeks back, I looked at the performance of Swift in the context of debug (e.g. non-optimized) builds. The developer workflow pain that I was having was significant. Of course, today a new build of Xcode dropped that finally (I jest a little) contained a new build of Swift: Swift v.1.2. So, is it any better? I’ve spent about ten minutes playing around with my proj
Swift Performance: Too Slow For Production | iMad
Much and more has been written about Apple’s new programming language, Swift. I even did a talk about it at Yow: Connected 2014. If you saw me there, you’d know that I’m not the biggest fan of Swift. I think the rollout of it has been an absolute disaster: the compiler is a shambles, the language design is inconsistent in places1 and it’s stupidly difficult to get working in libraries, particularl
[Xcode 6 / iOS 8] ユニットテストのようにパフォーマンスをテストするんだ！ | DevelopersIO
はじめに Xcode 6 でユニットテストのようにパフォーマンスをテストする機能が追加されました。 これによって重そうなロジックにパフォーマンスの測定を設定しておき常に計測することができます。 例えば、画像や動画、音声など圧縮データのエンコード／デコード処理、大量のデータをソートする処理、暗号化する処理などが、ざっと思いつく重い処理です。 今回はサンプルとしてログ出力で追加されたprintlnとNSLogのパフォーマンスを比較してみます。 測定してみる パフォーマンスの測定はユニットテストと同じように扱われますが、Assertがある訳ではなくself.measureBlock()の中で呼び出されたコードが計測対象になります。 新規にプロジェクトを作成するとTestクラスが作成されますが、そこにもself.measureBlock()が作成されるようになりました。 今回必要なソース テストさ
![[Xcode 6 / iOS 8] ユニットテストのようにパフォーマンスをテストするんだ！ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/34de6d57437c5cfc77b749f99e4483a7a1702539/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F06%2Fios81.png)
Swift Beta performance: sorting arrays
I was implementing an algorithm in Swift Beta and noticed that the performance was very poor. After digging deeper I realized that one of the bottlenecks was something as simple as sorting arrays. The relevant part is here: let n = 1000000 var x = [Int](repeating: 0, count: n) for i in 0..<n { x[i] = random() } // start clock here let y = sort(x) // stop clock here In C++, a similar operation take
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
