ビルド時間を短縮する方法/ XCodeでコンパイル時間を短縮する方法はありますか？

Question

XCodeプロジェクトのビルド時間を短縮するために一般にどのような戦略を使用できますか？私は主にXcode固有の戦略に興味があります。

私はXCodeを使用してiPhone開発を行っています。私のプロジェクトは徐々に大きくなっています。私は、コンパイル/リンク段階が私が望むよりも時間がかかり始めていることを知っています。

現在、私は：

• それを作るために静的ライブラリを使用したので 私のコードのほとんどは、私が掃除 コンパイル毎回ことと 私のメインのプロジェクトに

• を構築する必要はありません。

  アプリケーションからほとんどのリソースを削除しました。可能であれば、iPhone シミュレータの コード化されたファイルシステムパスでテストしてください。 リソースはh私はそれらに変更を加えると常に にパッケージされています。

「依存関係の確認」のフェーズは、私が望むよりも時間がかかるようです。それを減らすためのヒントもありがとう！

Answer 1

多くの場合、ヘッダーファイルの挿入を制御することができます。

"余分な"ヘッダーファイルをソースコードに含めると、コンパイルが大幅に遅くなります。これはまた、依存性チェックに必要な時間を増加させる傾向があります。

また、ヘッダーを含む代わりにforward declarationを使用すると、他のヘッダーが含まれているため、依存関係の数が大幅に削減され、すべてのタイミングに役立ちます。

Answer 2

個人的には、私のMac開発プロジェクトでコンパイラをLLVM-Clangに切り替えて、ビルド時間が劇的に減少しています。 LLVM-GCCコンパイラもありますが、これはビルド時間に役立つかどうかはわかりませんが、LLVM-ClangがiPhoneアプリのコンパイルでは機能しない場合でも試してみることができます。

私は100％確信していません。LLVMはiPhoneでの開発に対応していますが、私はそれがニュースフィードで読むことを覚えていると思います。それはあなたのコードで実装できる最適化ではありませんが、試してみる価値があります！

Answer 3

コンパイルを防止するために、頻繁に使用されるファイルに対して静的ライブラリを使用することについて言及しました。同様に、ヘッダーをコードに入れておくと、頻繁に使用されますが、プリコンパイルされたヘッダー内の静的なlibでは使用できません。少なくとも彼らは一度だけコンパイルされます。

プロジェクト全体に複数の編集タイプ（Obj-C、Obj-C++、C++など）がある場合は、問題を避けるために注意する必要があります。

Answer 4

簡単な答え：ローカルネットワーク上でXCodeを実行している別のマシンを追加してください。 XCodeはdistccを組み込んで分散コンパイルを行います。 Bonjourを使用して他のビルドホストを見つけることもでき、これを大幅に設定するプロセスが簡単になります。大規模なビルドでは、ビルドマシンの数にほぼ比例した速度向上が得られます（2台のマシンは半分、3台は3台など）。

これを設定する方法については、this development docを参照してください。また、プリコンパイルされたヘッダーと予測ビルドの使用など、ビルド時間の改善に役立つその他の戦略もあります。

編集：残念ながら、Xcodeの4.3のようAppleは、この機能を削除しました表示されます：http://lists.apple.com/archives/xcode-users/2012/Mar/msg00048.html

のXcode 5は、CIを行うことができ、サーバのバージョンがありますが、私は、これは、開発者が構築するアドホックのための任意の恩恵を与えるとは思えません。しかし、ビルド時間を劇的に短縮するはずの予期しない機能がいくつかあります。

Answer 5

ねえ、プロジェクトの物理構造を最適化することをお勧めします。これについての良い読書があります（少なくともC++の世界では）が、私はobjective-Cを行い、同じ原則がしばしば適用されます。

ここ回 をコンパイル改善する傾向があるプロジェクトの物理的な構造最適化についての素晴らしい記事は、だGames From Within: Physical Structure Part 1

幸運:)

Answer 6

Xcodeのは、同じ数にタスクのデフォルト設定を実行するために使用するスレッドの数あなたのCPUが持っているコア。たとえば、Intel Core i7を搭載したMacには2つのコアがあるため、デフォルトではXcodeは最大2つのスレッドを使用します。コンパイル時間はCPUバウンドではなくI/Oバウンドになることが多いため、Xcodeが使用するスレッド数を増やすと、コンパイル時のパフォーマンスが大幅に向上します。

3,4または8スレッドを使用するようにXcodeを設定し、どのケースがあなたのユースケースに対して最高のパフォーマンスを提供するかを調べてみてください。詳細についてはXcode User Defaultsを参照してください

defaults write com.apple.Xcode PBXNumberOfParallelBuildSubtasks 4

を：

あなたは次のようにXcodeの端末から使用するプロセスの数を設定することができます。

Answer 7

8GBのRAMを使用していない場合は、今すぐアップグレードしてください。

MacBook Proを4GBから8GBにアップグレードしました。プロジェクトのビルド時間は2:10から0:45になりました。私は改善によって溢れていた。また、きびきび研究や一般Xcodeのパフォーマンスインデックスのためのウェブブラウジングを作るなど

Answer 8

アプローチ「ことでより多くのハードウェアを投げ」について

クイックメモ...

概要：私は重要になってからSMALLスピード増加を経験しましたハードウェアのアップグレード

テスト：

旧Macbook Airは（1.86GHZ Core 2 DuoプロセッサONLY 2ギガバイトRAM） 真新しい対（唯一の違いは、そのハードウェアでなければなりません）クローンのMacBook上で正確に同じプロジェクトを実行します/ビルドしますMacBook Pro（2。3GHzのコアi7の8ギガバイトRAM）IPHONE 3GS ON

BUILDING
Macbook Airは午前1時 - 午前1時15
MacBook Proの〜1：00

=> 0速度増加の0時15分に

IPHONE 4S ON

BUILDING
MacBook Proの〜0：35
Macbook Airは〜0：50の速度の増加0の

=>〜15秒
**一部テスト：私の継続的な経験では2機

間SIMULATORのためのビルド時間の間に有意な差がありつくれんPHONEハードウェアに大きな変更を加えるとき..あなたは有意な増加を取得します（すなわち、 3GS vs iphone 5（またはそれについては4）の時間を構築する）..少なくとも私の経験では、制限要因は電話ハードウェア（コンピュータハードウェアではない）でした。

SO ..
オプション1を最速ビルド時間を取得するためには）、コードを書いて、高速なコンピュータや
オプション2にsimulaterで実行）最新のiphone

Answer 9

で、デバイス上に構築私は広範囲を書きました私は楽しんでるでのiOS開発サイクルを改善する方法についてのブログ記事：

1）dSYMバンドルの生成を停止：

Shaving off 50% waiting time from the iOS Edit-Build-Test cycle

それはに煮詰め。

2）Clangを使用している場合は-O4でコンパイルしないでください。

Answer 10

一つの巨大な先端（少なくともiOSのプロジェクトの場合）コンパイル時間を半減するためには、/ ビルド設定/アーキテクチャを設定するだけYESにアクティブアーキテクチャを構築することです。

これは（特に64ビットiPads/64ビットコンパイラの出現で）には、現在使用していないアーキテクチャ用のバイナリをビルドしていません。

をアプリストアに送信する際に再度有効にすることを忘れないでください。そうしないと、バイナリは検証されません。

Answer 11

一言：TmpDisk

1. 使用TmpDiskスピードをお楽しみください
2. /Volumes/1.5Gb/xcodeデータに1.5GB RAMディスク
3. 変更のXcode>設定>場所>得られたデータを作成します！

Answer 12

5960x CPUでHackintoshに切り替え、4.4GHzにオーバークロックしてXcodeのコンパイル時間を短縮しました。これは8コアと16スレッドです。すべてのMacを破壊するコンピュータの総費用は3000ドルです。しかし、私はヨセミテで最初に、それをセットアップして、少なくとも10日間過ごしました。私はMacOSをアップデートすることができず、Xcodeは新しいOSを必要としたが、6ヶ月のダウンタイムがあった。私はちょうどそれがシエラを実行して、人生は再び良いです。

私の2,8 GHz i7の二重コア16 GB RAM MacBook Proは、Hackintoshを20秒で75秒でプロジェクトをコンパイルします。 （プロジェクトのSwift、dlib、opencv C++）

しかし、最大の問題は、swiftをコンパイルするときに複数のスレッドを使用していないことです。これはボトルネックです、私は彼らがすぐにそれを修正することを願っています。

Answer 13

実行するたびにプロジェクト全体が再構築されると、おそらくXCode 7.0のバグでしょう。< = 8.1は苦労します。

ユーザー定義のビルド設定HEADERMAP_USES_VFSをYESにすると、毎回75秒から25秒に短縮されます。詳細はXcode 8 does full project rebuildを参照してください。

Answer 14

私のプロジェクトは、の構築時間が53秒から20秒に短縮された、いくつかの「前方宣言」最適化とともに、RAMドライブを使用するスクリプトを使用しました。

私はAppStoreでGUIを手に入れようと誘惑されましたが、むしろ というコマンドラインを選択しました。私はスクリプトをgitリポジトリの一部として入れました。

は、ビルド時間を表示するには、ターミナルで次のように入力します。 ツールバーのビルド時間を気づくこと

再起動のXcode「のデフォルトはcom.apple.dt.Xcode ShowBuildOperationDuration YESを書きます」。 （これは私の非クリーンなビルド時間を使用して目標 - c）

スクリプトを好みに合わせて調整します。 - スクリプトは、派生データフォルダ をクリアします。私は基本的にMacOSのが提供するhdiutilを使用 ：

#!/bin/sh 

#2 GIG RAM 
GIGA_BYTES=$((2*1024*1024*1024)) 

# a sector is 512 bytes 
NUMSECTORS=$((${GIGA_BYTES}/512)) 

#ram disk 
mydev=`hdiutil attach -nomount ram://$NUMSECTORS` 
newfs_hfs $mydev 

# make mount point 
MOUNT_POINT=/Users/your_user_name/Library/Developer/Xcode/DerivedData 

# ******************************************* 
# ** WARNING - MOUNT POINT WILL BE DELETED ** 
# ******************************************* 
rm -rf ${MOUNT_POINT} 
mkdir -p ${MOUNT_POINT} 

# mount 
mount -t hfs $mydev ${MOUNT_POINT} 
echo unmount $(MOUNT_POINT) 

効果を確認し、RAMドライブを制御するために：

mount      - see mount points 
umount mount_point   - unmount point 
diskutil list    - see disks 
diskutil eject /dev/diskX - eject the disk 
df -ahl      - see free space 

NOTE。 -kernelオプション（ディスクへのスワップなし）をオンにしてみましたが、マシン上で失敗しました。

新しいOSが登場すると、すぐに新しいファイルシステムのコピー機能が非常に高速になり、このスクリプトが冗長化される可能性があります。