㈠ 為什麼qtcreator的編譯如此之慢
對於QtCreator編譯速度慢的問題，有多種誤解需要澄清。
首先，將Qt編譯速度與MFC進行比較，這種觀點是不正確的。實際情況下，由於Qt庫的頭文件設計合理，採用前置聲明和公有類、私有類的模式，編譯效率遠高於MFC。MFC的編譯速度較快主要歸功於其默認啟用的預處理頭文件功能（PCH），這是所有C++項目都能利用的特性，並非MFC獨有。通過在.pro文件中添加`PRECOMPILED_HEADER = stable.h`，指定一個頭文件作為預處理文件，可以實現與MFC類似的效果。在`stable.h`文件中包含所有需要的Qt頭文件，可以有效避免編譯時引入過多代碼。
為了進一步提高編譯速度，可以使用`QMAKE_CXXFLAGS += /MP`指令來啟用並行編譯，利用多個編譯進程同時處理不同cpp文件。這種方法比MFC的PCH更優，因為MFC的PCH配置容易出錯，而Qt的配置則寫在.pro文件中，一旦配置正確，穩定性較高。
對於大項目而言，硬碟性能是影響編譯速度的主要瓶頸。使用SSD硬碟時，編譯速度大約為20分鍾左右；若使用機械硬碟，速度會降低約70%；使用內存檔編譯則可提高30%的速度。如果編譯速度仍然慢於預期，應檢查代碼中是否存在冗餘或不必要的頭文件包含。
關於Qt本身的編譯速度，通常情況下並不慢，慢點主要體現在WebKit庫和示常式序的編譯上。默認情況下，Qt會編譯所有的庫和示例，而WebKit項目因其泛型技術使用廣泛，編譯時間較長。對於僅需要核心庫的項目，編譯速度會大幅提高，例如，僅編譯QtCore可能只需1分鍾，QtGui則大約5分鍾。
對於Windows平台，建議使用Visual C++ 2008作為編譯器。Qt與Visual C++的集成度較高，使用Visual C++ 2008+Qt進行項目開發效率會更高。此外，安裝Visual Assist可以進一步提升開發效率。
總結而言，QtCreator編譯速度慢的問題通常與項目規模、編譯器選擇和配置有關。通過優化配置和使用適當的編譯工具，可以顯著提高編譯效率。
㈡ Xcode編譯慢打包慢解決方法
1. 提高 XCode 編譯時使用的線程數
defaults write com.apple.Xcode 48 cpu 佔用會特別高 達到150%的樣子,15寸 設置48比較好，否則操作其他因員工可能會卡
XCode 默認使用與 CPU 核數相同的線程來進行編譯，但由於編譯過程中的 IO 操作往往比 CPU 運算要多，因此適當的提升線程數可以在一定程度上加快編譯速度。本人採用的是 4 核的 CPU ，將線程數改為 8 後編譯速度略有提升。
2. 將 Debug Information Format 改為 DWARF
在工程對應Target的Build Settings中，找到Debug Information Format這一項，將Debug時的DWARF with dSYM file改為DWARF。
這一項設置的是是否將調試信息加入到可執行文件中，改為DWARF後，如果程序崩潰，將無法輸出崩潰位置對應的函數堆棧，但由於Debug模式下可以在XCode中查看調試信息，所以改為DWARF影響並不大。這一項更改完之後，可以大幅提升編譯速度。
// 這一條暫時不用管，默認配置
3. 將 Build Active Architecture Only 改為 Yes
在工程對應Target的Build Settings中，找到Build Active Architecture Only這一項，將Debug時的No改為Yes。
這一項設置的是是否僅編譯當前架構的版本，如果為No，會編譯所有架構的版本。需要注意的是，此選項在Release模式下必須為Yes，否則發布的ipa在部分設備上將不能運行。這一項更改完之後，可以顯著提高編譯速度。
在設置完以上三個項之後，相信編譯時間會縮短很多。
4. 如何關掉 CCache 提高編譯打包速度呢編寫腳本,文件名稱ccache
放到Xcode項目根目錄，然後
詳情見這篇帖子
https://www.jianshu.com/p/c9e3fb3dfa53
5. 去掉打包緩存
~/Library/Developer/Xcode/Procts
㈢ 為什麼 Qt Creator 的編譯如此之慢
取自知乎上的一篇文章
作者：姚冬
我是來反對樓上某些答案的。
我曾經用MFC寫了金山詞霸（大約20多萬行），又用Qt寫了YY語音（大約100多萬行），算是對兩種框架都比較有經驗。
糾正幾個錯誤的認識。
1. 「用Qt寫的程序編譯比MFC慢」的說法是錯誤的
絕對錯誤，單位代碼行數編譯Qt遠比MFC快得多，因為Qt庫的頭文件設計非常好，盡量都使用了前置聲明，避免了頭文件嵌套，幾乎所有類都使用了公有類和私有類的設計，把沒必要公開的聲明放到私有頭文件里，避免了編譯時引入過多代碼。而MFC沒有這樣的設計。
至於大家感覺MFC快主要原因是MFC工程默認打開了編譯預處理頭文件（PCH），但是這是VC編譯器的特性，所有C++程序都可以用，不是MFC特有，Qt也可以使用 PCH
方法很簡單，在你的 .pro 文件中加入一行
PRECOMPILED_HEADER = stable.h
指定 Stable.h這個頭文件作為編譯預處理文件，MFC里這個文件一般叫stdafx.h
然後在 stable.h里 包含你所用到的所有 Qt 頭文件，如果你用了很多qt的類可以直接包含所有
比如 ：
#include <QtCore>
#include <QtGui>
這兩個文件里又包含了幾乎所有Qt常用類
不用擔心，即使包含了所有頭文件也沒關系，有了PCH再多頭文件也沒影響。
如果你還想編譯再快點，可以在 .pro里加入下面一行
QMAKE_CXXFLAGS += /MP
指定/mp編譯選項，編譯器將使用並行編譯，同時起多個編譯進程並行編譯不同的cpp
而且QT這種引入PCH的方法比MFC的好，由於MFC的PCH選項是每個工程逐個指定的，很容易被某些人搞壞，我曾經無數次修復PCH問題，但是Qt的選項是寫在.pro里的，寫一次就永遠不會錯。
MFC一旦弄壞了PCH，編譯也慢得令人發指。
給個參考時間吧，YY最新版本大約 100多萬行C++代碼，rebuild debug和releae總共需要20多分鍾，機器是i5 四核SSD硬碟。其實對於大項目硬碟才是瓶頸，如果換機械硬碟要慢差不多70%，有個同事用10G內存做了個內存檔編譯，還能快30%。
如果你比這個慢，請檢查自己的代碼問題。
2. 「QT本身編譯慢」的說法是錯的
Qt本身其實編譯並不慢，慢的是webkit庫和例子程序，你如果不改任何選項默認是會編譯所有的，webkit本身就是個恐龍級項目，用了太多泛型技術，編譯非常慢。另外Qt里附帶了數百個例子工程，都編譯一邊也很慢。如果僅編譯QT核心庫是很快的，比如QtCore只需要1分鍾，QtGui大約5分鍾。
送個福利（僅限windows vc＋＋ 2008）：
configure.exe -qt-libjpeg -qt-zlib -qt-libpng -qt-libjpeg -qt-gif -no-libtiff -no-libmng -nomake examples -nomake demos -no-webkit -nomake doc -no-plugin-manifests -no-exceptions -no-rtti -no-qt3support -no-openssl -no-opengl -no-multimedia -no-3dnow -no-native-gestures -no-style-motif -no-style-cde -no-style-cleanlooks -no-style-plastique -no-sql-sqlite -no-dbus -platform win32-msvc2008
這是我自己用的Qt編譯前的配置命令行，把我自己用不到的都去掉了，這樣配置編譯就快很多了。
我把 webkit examples demos 等大傢伙都去掉了。如果你真的需要這些，可以安裝Qt sdk裡面有編譯好的版本。
補充：Qt creator只是IDE，不是編譯器，編譯慢真的不關他的事，要看你具體用的編譯器是什麼。一般來說在Windows下就是minGW，也就是一個移植版本的GCC，的確是不如VC++里的CL快的。
如果是其它平台，那麼編譯器可以換成LLVM的clang，那就快很多了。
在Windows下來是用VC++吧，推薦VC2008，Qt和VC的IDE結合非常好，我現在的項目都是用VC2008+QT的，開發效率很高，記得裝Visual Assist哦。
qmake -tp vc
可以用 .pro生產 .vcproj的VC工程文件，可以用VC++打開編譯。
㈣ vs2017緙栬瘧浠ｇ爜鐢熸垚鐗瑰埆鎱錛
VisualStudio緙栬瘧寰堟參瑙ｅ喅鍔炴硶錛氭墦寮vs2010鐨勫伐鍏烽夐」錛岀幆澧>甯歌勪箣涓嬫煡鐪嬧濊嗚変綋楠屸濋厤緗錛屽畠榛樻橀噹瀵熻ら夋嫨浜嗏濆熀鑴婅佷簬瀹㈡埛絝鎬ц兘鑷鍔ㄨ皟鏁磋嗚変綋楠屸濆苟鍚鐢ㄧ‖浠跺渾鑼勫浘褰㈠姞閫燂紝鍙栨秷閫夋嫨榪欎釜閫夋嫨銆
㈤ ue5c++編譯慢
ue5c++編譯慢，這個說法是錯誤的。根據查詢相關資料顯示：ue5c++本身其實編譯並不慢，慢的是webkit庫和例子程序，不改任何選項默認是會編譯所有的，webkit本身就是個恐龍級項目，用了太多泛型技術，編譯非常慢。另外Qt里附帶了數百個例子工程，都編譯一邊也很慢。僅編譯QT核心庫是很快的，比如QtCore只需要1分鍾，QtGui大約5分鍾。