① 為什麼 Qt Creator 的編譯如此之慢
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++打開編譯。
在計算機這個行業技術達到瓶頸。1、選擇適合項目的語言，即便是放棄自己熟悉的語言。
2.與他人分享經驗.
3、別害怕失敗
我過去通常不喜歡分享代碼。我討厭分享代碼，我擔心別人會因代碼編的太爛而批評我。我之所以對自己的編程能力覺得毫無把握，是因為我希望可以做得更好。害怕別人說三道四，這會使我想在一個角落裡隱藏起來。
4、對自己要有耐心
我不敢承認這點：我在過了很久後才明白了這個道理。你對自己要有耐心，急於求成可不行，也就會存在這種可能性：自己把自己搞得筋疲力盡、導致倦怠。我不想讓你遇到這種情況。
③ aix小機上 如何看程序的瓶頸在哪兒
AIX 全名為（Advanced Interactive Executive），它是IBM 公司的Unix操作系統，
整個系統的設計從網路、主機硬體系統，到操作系統完全遵守開放系統的原則。
下面對AIX 作以介紹。
RS/6000 採用IBM 的UNIX操作系統-AIX作為其操作系統。這是一
個目前操作系統界最成功，應用領域最廣，最開放的第二代的UNIX系
統。它特別適合於做關鍵數據處理（CRITICAL）。
AIX 包含了許多IBM 大型機傳統受歡迎的特徵，如系統完整性，系統可管理
性和系統可用性。
在 AIX 操作系統上，有許多的資料庫和開發工具，用戶除了選用已有的應用
軟體外，還可以根據各自的需要進行開發。
此外，在AIX 之上，有一組功能強，使用方便的系統管理工具。對於異種平台
互存，互操作有很成熟的解決方案。
由於該 UNIX 的先進的內核技術和最好的開放性，因此，雖然RS/6000
從宣布到今天只有短短的5 年多的時間，它已在各行各業有了廣泛的運用，
並在1993和1994年連續二年在MIDRANGE商用 UNIX 領域處於第一位。
RISC SYSTEM/6000的操作系統是AIX ，它是性能卓越的、開放的
UNIX，匯集了多年來計算機界在UNIX上的研究成果，以IBM 在計算機
體系結構、操作系統方面40多年極其豐富的經驗。最大限度的使用RISC
技術，安裝了象AIX 這樣的具備工業界實力的UNIX操作系統。
它既可連接SAA 體系結構，又能與非IBM 系統的網路相連，因此，可以
和多數專業銀行現有的系統實現互連，這對今後業務系統拓展將帶來極大的
靈活性，並降低投資。
AIX 遵循一系列的國際標准：
* IEEE POSIX1004.1－1990
* X/OPEN 移植指南ISSUE3的基本級（XPG3）
* AES/OS REVISION A （OSF/1 LEVEL 2 資格）
* FIPS 151－1
* AIX的編譯器： XLC、C++(可選)、FORTRAN(可選)、PASCAL(可選)、COBOL(可選)
* ADA 的編譯器已達到XPG3「成員」級的認可。
* AIX 支持多用戶、多任務。
AIX有一些其它特性包括：
AIX 提供了3 種SHELL ：SYSTEM V的KORN、BOURNE SHELL和4.3BSDC
SHELL作為可選擇的UNIX系統界面；
安全設施滿足TCB （Trusted Computing Base）的C2級；
實時處理能力，這對於「面向交易」的應用至關重要（如零售業
和銀行等），它使RS/6000 獲得極高的響應和吞吐量；
虛擬存儲管理，當需要時，可將一些不常用的模塊轉送至外存，
提高內存的可利用性。
先進的文件系統，使得系統管理更加有效，並提高了數據可靠性
以及完整性。
能兼容Dos 應用程序和數據。
InfoExplorer，快速信息超文本索引系統- 不僅包括文字，而且
對包含聲音、圖像的索引系統，這是個聯機的文件介面。包括全部的
超文本的索引和查找，以及面向任務和坐標的多重導引和索引系統。
這個文字及圖形索引系統以一個靈活的、基於任務的方式去使用詳細
資料及培訓資料。
高級系統管理工具（SMIT，System Management Interface Tool）。
提供一級菜單驅動程序，諸如完成軟體的安裝與設置、設備的設置及
管理、問題的測定、存貯管理等。可以自動地進行I/O 設備設置，
ASCII 終端也可充當系統控制台。在LAN 上可以進行遠程系統的安裝。
系統工作負載
系統工作負載的完整准確的定義對於預測或理解它的性能是很關鍵的。在衡量系統性能時，工作負載的不同可能會比 CPU 時鍾速度或隨機訪問存儲器（RAM）大小不同帶來更多的變化。工作負載的定義不僅必須包含向系統發送的請求的類型和速率，還要包含將要執行的確切軟體包和內部應用程序。
包括系統將在後台處理的工作也很重要。例如，如果一個系統包含通過 NFS 載入且由其它系統頻繁訪問的文件系統，那麼處理那些訪問很可能是總體工作負載中非常重要的一部分，即使該系統不是正式的伺服器也是如此。
已進行標准化從而允許在不同系統之間進行比較的工作負載稱為基準程序。但是，很少有實際的工作負載能完全符合基準程序的精確演算法和環境。即使是那些最初從實際的應用程序發展而來的行業標准基準程序也已經過簡化和均勻化，從而使它們可移植到大量的硬體平台上。使用行業標准基準程序唯一有效的方法是減小將接受嚴肅評估的候選系統的范圍。因此，在嘗試理解系統的工作負載和性能時不應該只依賴基準測試結果。
可以將工作負載分為以下類別：
多用戶
由多個用戶通過各自的終端提交的工作組成的工作負載。通常，這種工作負載的性能目標有兩種可能，即在保留指定的最壞情況響應時間條件下最大化系統吞吐量，或者對於固定不變的工作負載獲得盡可能快的響應時間。
伺服器
由來源於其它系統的請求組成的工作負載。例如，文件伺服器的工作負載主要是磁碟讀寫請求。它是多用戶工作負載（加上 NFS 或其它 I/O 活動）的磁碟 I/O 部分，所以適用同樣的目標，即在給定的相應時間限制下最大化吞吐量。其它的伺服器工作負載由諸如數學計算密集的程序、資料庫事務、列印機作業之類的項組成。
工作站
由單獨的用戶通過鍵盤提交工作和在該系統的顯示器上接收結果組成的工作負載。通常這種工作負載的最高優先順序性能目標是使用戶請求的響應時間最短。
性能目標
在定義了系統必須處理的工作負載後，可以選擇性能標准並根據這些標准設定性能目標。計算機系統的總體性能標準是響應時間和吞吐量。
響應時間是提交請求和返回該請求的響應之間使用的時間。示例包括：
資料庫查詢花費的時間
將字元回顯到終端上花費的時間
訪問 Web 頁面花費的時間
吞吐量是對單位時間內完成的工作量的量度。示例包括：
每分鍾的資料庫事務
每秒傳送的文件千位元組數
每秒讀或寫的文件千位元組數
每分鍾的 Web 伺服器命中數
這些度量之間的關系很復雜。有時可能以響應時間為代價而得到較高的吞吐量，而有時候又要以吞吐量為代價得到較好的響應時間。在其它情況下，一個單獨的更改可能對兩者都有提高。可接受的性能基於合理的吞吐量與合理的響應時間相結合。
在規劃或調諧任何系統中，當處理特定的工作負載時一定要保證對響應時間和吞吐量都有明確的目標。否則，有可能存在一種風險，那就是您花費了分析時間和物力改善的僅僅是系統性能中一個次要的方面。
程序執行模型
為了清楚地檢查工作負載的性能特徵，需要有一個動態而非靜態的程序執行模型，如下圖所示。
圖 1. 程序執行層次結構. 該圖形以一個三角形為基礎。左邊代表和右邊適當的操作系統實體匹配的硬體實體。程序必須從存儲在磁碟上的最低級別開始，到最高級別的處理器運行程序指令。例如，從底部到頂部，磁碟硬體實體容納可執行程序；實內存容納等待的操作系統線程和中斷處理程序；轉換後備緩沖區容納可分派的結程；高速緩存中包含當前分派的線程和處理器流水線；而寄存器中包含當前的指令。
程序為了運行必須沿著硬體和操作系統層次結構並行向上前進。硬體層次結構中的每個元素都比它下面的元素稀少和昂貴。不僅程序不得不為了每個資源和其它程序競爭，而且從一個級別過渡到下一級別也要花時間。為了理解程序執行動態，需要對層次結構中每一級別有個基本的了解。
硬體層次結構
通常，從一個硬體級別移動到另一級別所需要的時間主要由較低級別的等待時間（從發出請求到接受到第一批數據的時間）組成。
固定磁碟
對於一個在單機系統中運行的程序而言，最慢的操作是從磁碟上取得代碼或數據，這是因為有下列原因：
必須引導磁碟控制器直接訪問指定的塊（排隊延遲）。
磁碟臂必須尋道以找到正確的柱面（尋道等待時間）。
讀／寫磁頭必須等候直到正確的塊旋轉到它們下面（旋轉等待時間）。
數據必須傳送到控制器（傳送時間）然後傳遞到應用程序中（中斷處理時間）。
除了程序中顯式的讀或寫請求以外，還有許多原因導致磁碟操作緩慢。頻繁的系統調諧活動證明是不必要地跟蹤了磁碟 I/O。
實內存
實內存通常稱為隨機存取存儲器或 RAM，它比磁碟速度快，但每個位元組的開銷非常昂貴。操作系統盡量只把當前使用的代碼和數據保存在 RAM 中，而把任何額外的內容存儲在磁碟上，或者決不首先把它們帶入 RAM 中。
然而，RAM 的速度不一定比處理器快。通常在硬體意識到 RAM 訪問需求與處理器可使用數據或指令的時間之間，會出現許多處理器周期的 RAM 等待時間。
如果要訪問存儲到磁碟上（或者尚未調進）的某一虛擬內存頁，則會產生一個缺頁故障，並且程序的執行暫掛直到該頁從磁碟讀取。
轉換後備緩沖區（TLB）
使程序員不會受限於系統的物理局限性的方法是實現虛擬內存。程序員在設計和編寫程序時認為內存非常大，系統將負責將程序中指令和數據的虛擬地址轉換成需要用來從 RAM 取得的指令和數據的實際地址。因為這個地址轉換過程可能很費時，系統將最近訪問過的虛擬內存頁的實際地址保存在一個叫轉換後備緩沖區（TLB）的高速緩存中。
只要運行中的程序繼續訪問程序和數據頁中的一小部分，則完整的從虛擬到實際頁地址的轉換過程就不需要在每次 RAM 訪問的時候都重做一次。當程序試圖訪問的虛擬內存頁沒有 TLB 入口（即 TLB 未命中）時，則需要大量的處理器周期（即 TLB 未命中等待時間）來進行地址轉換。
高速緩存
為了將程序必須經歷的 RAM 等待時間減到最小，系統為指令和數據組織了高速緩存。如果所需的指令和數據已在高速緩存中，則產生高速緩存命中，處理器就可在下一個周期立刻使用該指令或數據。否則產生高速緩存未命中，伴隨有 RAM 等待時間。
在某些系統中，有兩到三級高速緩存，通常稱它們為 L1、L2 和 L3。如果一個特殊的存儲器引用導致 L1 未命中，則檢查 L2。如果 L2 產生未命中，則引用轉至下一個級別，要麼是 L3（如果存在），要麼是 RAM。
高速緩存的大小和結構根據型號的不同而有不同，但是有效使用它們的原理是相同的。
流水線和寄存器
流水線型超標量體系結構使得在某些情況下可以同時處理多個指令。大批的通用寄存器和浮點寄存器使得可以將相當多的程序數據保存在寄存器中，而不需要頻繁存儲和重新裝入。
可以設計優化編譯器最大限度地利用這些能力。當生成產品程序時，無論程序有多小編譯器的優化函數都應該能使用。Optimization and Tuning Guide for XL Fortran, XL C and XL C++ 中描述了如何將程序調諧到最大性能。
軟體層次結構
程序為了運行還必須逐步執行軟體層次結構中的一系列步驟。
可執行程序
當請求運行某個程序時，操作系統執行一些操作以將磁碟上的可執行程序轉換成運行中的程序。首先，必須掃描當前 PATH 環境變數中的目錄以查找程序的正確副本。然後，系統裝入程序（不要和 ld 命令混淆，該命令是個綁定程序）必須解析出從程序到共享庫的任何外部引用。
為了表示用戶的請求，操作系統將創建一個進程或一組資源（例如專用虛擬地址段），任何運行中的程序都需要該進程或資源。
操作系統也會在該進程中自動創建一個單獨的線程。線程是一個單獨程序實例的當前執行狀態。在 AIX 中，對處理器和其它資源的訪問是根據線程來分配而不是根據進程分配的。應用程序可在一個進程中創建多個線程。這些線程共享由運行它們的進程所擁有的資源。
最後，系統轉移到程序的入口點。如果包含入口點的程序頁還不在內存中（可能因為程序最近才編譯、執行和復制），則由它引起的缺頁故障中斷將該頁從它的後備存儲器中讀取出來。
中斷處理程序
通知操作系統發生了外部事件的機制是中斷當前運行線程並將控制轉移到中斷處理程序。在中斷處理程序可以運行之前，必須保存足夠的硬體狀態以保證在中斷處理完成後系統能恢復線程的上下文。新調用的中斷處理程序將經歷在硬體層次結構中上移帶來的所有延遲（除了頁面故障）。如果該中斷處理程序最近沒有運行過（或者中間程序很節約時間），那麼它的任何代碼或數據不太可能保留在 TLB 或高速緩存中。
當再次調度已中斷的線程時，它的執行上下文（如寄存器內容）邏輯上將得到恢復，以便它可以正確運行。然而，TLB 和高速緩存的內容必須根據程序的後繼請求重新構造。因此，作為中斷的結果，中斷處理程序和被中斷的線程都可能遇到大量的高速緩存未命中和 TLB 未命中延遲。
等待線程
無論何時只要執行的程序發出不能立刻滿足的請求，例如同步 I/O 操作（顯式的或缺頁故障的結果），該線程就會處於等待狀態，直到請求完成為止。除了請求本身所需的時間以外，通常這還會導致另外一些 TLB 和高速緩存的延遲時間。
可分派線程
當某個線程可分派但不在運行時，它不能完成任何有用的事情。更糟的是，正運行的其它線程可能導致重新使用該線程的高速緩存線路並將實內存頁收回，從而引起最終分派時出現更多的延遲。
當前已分派的線程
調度程序選擇對使用處理器有強烈要求的線程。在『CPU 調度程序性能概述』中討論了影響該項選擇需要考慮的事項。當分派線程後，處理器的邏輯狀態恢復成線程中斷時有效的狀態。
當前的機器指令
如果未出現 TLB 或高速緩存未命中的情況，絕大多數機器指令都能在單個處理器周期內執行。相比之下，如果程序迅速轉換到該程序的不同區域且訪問大量不同區域中的數據，就會產生較高的 TLB 和高速緩存未命中率，執行每條指令使用的平均處理器周期數（CPI）可能大於 1。這種程序被認為有較差的局域性引用能力。它也許在使用必需的最少指令數來做這個工作，但是要消耗大量不必要的周期數。部分是因為指令數和周期數之間相關性較弱，檢查程序列表來計算路徑長度不會再直接產生一個時間值。由於較短的路徑通常比較長的路徑快，所以速率根據路徑長度率的不同而明顯不同。
編譯器用完善的方法重新安排代碼從而將程序執行所需的周期數降到最小。追求最佳性能的程序員必須首先致力於確保編譯器具有有效優化代碼所需的全部信息，而不是試圖事後批評編譯器的優化技術（請參閱『預處理器和編譯器的有效使用』）。優化有效性的實際衡量標準是可信工作負載的性能。
系統調諧
在有效實現應用程序後，系統總體性能的進一步提高就成了系統調諧考慮的一個問題。系統級調諧包含的主要組件有：
通信 I/O
取決於工作負載的類型與通信鏈路的類型，可能需要調諧以下的一個或多個通信設備驅動程序：TCP/IP 或 NFS。
固定磁碟
邏輯卷管理器（LVM）控制文件系統的位置和磁碟上調頁空間，這可能會極大地影響系統經歷的尋道等待時間。磁碟設備驅動程序控制執行 I/O 請求所遵從的順序。
實內存
虛擬內存管理器（VMM）控制空閑實內存幀的池，並決定何時從何處取用幀來補充該池。
運行線程
調度程序確定接下來由哪個可調度實體接收控制權。在 AIX 中，可調度實體是線程。請參閱『線程支持』。
性能調諧過程介紹
性能調諧主要是資源管理問題和正確的系統參數設置。調諧工作負載和系統以有效利用資源由下列步驟組成：
識別系統中的工作負載
設置目標：
確定如何評測結果
量化目標和區分目標的優先順序
識別限制系統性能的關鍵資源
最小化工作負載的關鍵資源要求：
如果可選擇的話，使用最適當的資源
減少個別程序或系統函數對關鍵資源的要求
結構化資源的並行使用
修改資源的分配以反映優先順序
更改個別程序的優先順序或資源限制
更改系統資源管理參數的設置
重復步驟 3 到步驟 5 直到滿足目標（或者資源飽和）
如果必要的話，使用其它資源
在系統性能管理的每個階段都有相應的工具（參閱附錄 A 『監視和調諧命令和子常式』）。這些工具有些可從 IBM 得到；另一些是第三方產品。下圖說明在一個簡單的 LAN 環境中性能管理的各階段。
圖 2. 性能階段. 該圖用五個加權的圓圈說明對系統性能調諧的各步驟：規劃、安裝、監視、調諧和擴展。每個圓圈代表系統處於不同的性能狀態：空閑、不均衡、均衡和過載。實質上就是擴展一個過載的系統、調諧系統直到它是均衡的、監視不均衡的系統並且在需要擴展時安裝更多的資源。
識別工作負載
系統執行的所有工作都必須能夠識別。特別是在 LAN 連接的系統中，通過系統的用戶之間僅有的非正式協議，可以輕松地開發出一組復雜的交叉安裝的文件系統。這些文件系統必須被識別出來並作為任何調諧活動的一部分進行考慮。
對於多用戶工作負載，分析員必須量化一般情況和高峰期的請求率。確定用戶實際與終端交互時間的實際比例也是很重要的。
該識別階段中的一個要素是決定必須對生產系統進行評估和調諧活動，還是在另一系統上（或「切換」）用實際工作負載的模擬型式來完成評估和調諧活動。分析員必須針對非生產環境的靈活性權衡來自於生產環境結果的較大可靠性，分析員可在非生產環境中進行試驗，當然試驗所冒的風險是性能下降或更糟。
設置目標的重要性
雖然可以根據可測數量設置目標，但實際希望的結果往往帶有主觀性，比如令人滿意的響應時間。進一步講，分析員必須抵擋住調諧可測量的東西而不是對他而言是重要東西的誘惑。如果沒有系統提供的評估能符合所要求的改進，那麼就必須對該評估進行設計。
量化目標最有價值的方面不是選擇達到的數字，而是對（通常）多個目標的相對重要性進行公開判定。如果這些優先順序沒有事先設定且不是每個相關的人都理解的話，分析員在沒有進行頻繁咨詢之前不能作出任何折衷的決定。分析員還容易對用戶的反應或管理性能中一些已經被忽略的方面而感到吃驚。如果系統的支持和使用跨過了組織的邊界，您可能需要供應商和用戶之間的書面服務級協議，可確保對性能目標和優先順序有一個清楚而共同的理解。
識別關鍵資源
通常，給定工作負載的性能可由一兩種關鍵系統資源的可用性和速度決定。分析員必須正確識別出那些資源，否則會冒險陷入無休止的嘗試出錯操作。
系統具有物理資源和邏輯資源。關鍵的物理資源通常比較容易識別，因為較多的系統性能工具可用來評估物理資源的利用率。通常最影響性能的物理資源如下：
CPU 周期
內存
I/O 匯流排
不同的適配器
磁碟臂
磁碟空間
網路訪問
邏輯資源不太容易識別。邏輯資源通常是對物理資源進行分區的編程抽象。進行分區的目的是共享和管理物理資源。
構建於其上的物理資源和邏輯資源的一些示例如下：
CPU
處理器時間片
內存
頁面幀
堆棧
緩沖區
隊列
表
鎖和信號量
磁碟空間
邏輯卷
文件系統
文件
分區
網路訪問
會話
信息包
通道
了解邏輯資源和物理資源是很重要的。因為缺少邏輯資源線程可能阻塞，就像因為缺少物理資源而阻塞一樣，擴展下層物理資源未必能保證創建附加的邏輯資源。例如，考慮使用 NFS 塊 I/O 守護程序 biod。客戶機上的一個 biod 守護程序要求處理每個暫掛的 NFS 遠程 I/O 請求。因此，biod 守護程序的數量限制了能同時運行的 NFS I/O 操作的數量。當缺少 biod 守護程序時，系統檢測會指示 CPU 和通信鏈路只使用了很少一部分。您可能有系統未充分利用（並且很慢）的假象，事實上這時是因為缺少 biod 守護程序從而限制了其餘的資源。biod 守護程序使用處理器周期和內存，但您不能簡單地通過添加實內存或將它轉移到一個更快的 CPU 上來修正這個問題。解決方案是創建更多的邏輯資源（biod 守護程序）。
在應用程序開發過程中可能不經意間創建邏輯資源和瓶頸。傳遞數據或控制設備的方法可以有效地創建一個邏輯資源。當偶然創建這樣的資源時，通常沒有工具可監視它們的使用，也沒有介面控制它們的分配。它們的存在可能不會引起重視，直到某個特定性能問題出現時就會突出它們的重要性。
最小化關鍵資源要示
下面討論在三個級別上考慮最小化工作負載的關鍵資源要求。
使用適當的資源
決定在一個資源上使用另一個資源時應該理智地考慮並且頭腦中要有明確的目標。在應用程序開發過程中有一個選擇資源的示例，即通過增加內存消耗來減少 CPU 的消耗來達到一個平衡。用於演示資源選擇的公共的系統配置決策為：是將文件放置在單獨的本地工作站上，還是放置在遠程伺服器上。
減少關鍵資源的要求
對於本地開發的應用程序，可用多種方法檢查程序以便其更有效地執行相同的功能或除去不需要的功能。在系統管理級別上，爭用關鍵資源的低優先順序工作負載可以移動到其它系統中、在其它時間運行或由「工作負載管理器」控制。
結構化資源的並行使用
因為工作負載需要運行多個系統資源，從而可以利用這樣的事實，即資源是獨立的且可以並行使用。例如，操作系統預讀演算法檢測到程序在順序訪問文件的事實，因此它調度並行執行的其它順序讀取操作，同時應用程序還處理先前的數據。並行也用於系統管理。例如，如果某個應用程序同時訪問兩個或多個文件且如果同時訪問的這些文件存放在不同的驅動器上，那麼添加一個額外的磁碟驅動器可能會提高磁碟 I/O 的速率。
資源分配優先順序
操作系統提供了一些方法來區分活動的優先順序。有些在系統級別上設置，比如磁碟調步。其它的例如進程優先順序可由單個用戶設置以反映連接到特定任務上的重要性。
重復調諧步驟
性能分析的一個公認的真理是接下來總有瓶頸出現。減少某個資源的使用意味著另一資源限制了吞吐量或響應時間。例如，假設我們的系統中有下列的利用率級別：
CPU：90% 磁碟：70% 內存：60%
這個工作負載是 CPU 受限的。如果成功的調諧工作負載使得 CPU 負載從 90% 降到 45%，則可望在性能上有兩倍的改善。不幸的是現在的工作負載是 I/O 受限的，它有下列的近似利用率：
CPU：45% 磁碟：90% 內存：60%
改善後的 CPU 利用率允許程序立刻提交磁碟請求，但接下來我們會受到由磁碟驅動器的容量施加的限制。性能改善也許是 30% 而不是預期的 100%。
總是存在一個新的關鍵資源。重要的問題是使用手邊的資源是否已經滿足性能目標。
注意: 用 vmtune、schedtune 和其它調諧命令產生的不正當系統調諧可能導致意外的系統行為，例如降低系統或應用程序的性能或系統暫停。更改僅應在性能分析識別出瓶頸時才適用。
注:
對於性能相關的調諧設置，不存在什麼一般建議。
應用額外的資源
在前述所有的方法都用盡後如果系統性能仍不能滿足它的目標，則必須增強或擴展關鍵資源。如果關鍵資源是邏輯資源且下層物理資源足夠，則無需額外代價就可以擴展邏輯資源。如果關鍵資源是物理資源，分析員必須研究一些額外的問題：
必須增強或擴展關鍵資源到什麼程度才可以終止瓶頸？
系統性能會滿足它的目標嗎？或另外的資源會首先飽和嗎？
如果有一串關鍵資源的話，增強或擴展所有這些資源或與另一系統劃分當前工作負載是否更節省成本呢？
性能基準
當試圖比較不同環境中給定軟體的性能時，常會遇到許多可能的錯誤，一些是技術上的，一些是概念上的。本節包含主要的提示信息。本書其它各節討論評測過去和特定處理時間的不同方法。
評測處理系統調用需要花費的時間（掛鍾）時，需要獲取一個由下列內容組成的數字：
執行正運行服務的指令所需要的確切時間
處理器等待內存中的指令或數據時延遲的不同時間（也就是說，高速緩存和 TLB 不命中的代價）
在調用開頭和結束訪問時鍾所需要的時間
由周期性事件如系統定時器中斷所消耗的時間
由或多或少的隨機事件消耗的時間，如 I/O
為了避免報告一個不精確的數字，常常要求多次評測工作負載。因為所有的外部的因素都會增加處理時間，典型的評估集有一個曲線的形式
④ 為什麼我的電腦無法編譯程序
因為其他的電腦上沒有相關的運行庫，因此無法運行。
但可以這樣解決，打開工程或項目的屬性，在常規選項卡中設置：使用MFC作為靜態鏈接庫（不同版本的描述不盡相同，但都有靜態兩個字），設置後再編譯就可以了。
⑤ 如何加快C++代碼的編譯速度
C++代碼一直以其運行時的高性能高調面對世人， 但是說起編譯速度，卻只有低調的份了。比如我現在工作的源代碼，哪怕使用Incredibuild調動近百台機子，一個完整的build也需要四個小時，恐怖！！！雖然平時開發一般不需要在本地做完整的build，但編譯幾個相關的工程就夠你等上好一段時間的了（老外管這個叫monkey around，相當形象）。想想若干年在一台單核2.8GHZ上工作時的場景 - 面前放本書，一點build按鈕，就低頭讀一會書~~~往事不堪回首。
可以想像，如果不加以重視，編譯速度極有可能會成為開發過程中的一個瓶頸。那麼，為什麼C++它就編譯的這么慢呢？
我想最重要的一個原因應該是C++基本的"頭文件-源文件"的編譯模型：
每個源文件作為一個編譯單元，可能會包含上百甚至上千個頭文件，而在每一個編譯單元，這些頭文件都會被從硬碟讀進來一遍，然後被解析一遍。
每個編譯單元都會產生一個obj文件，然後所以這些obj文件會被link到一起，並且這個過程很難並行。
這里，問題在於無數頭文件的重復load與解析，以及密集的磁碟操作。
下面從各個角度給出一些加快編譯速度的做法，主要還是針對上面提出的這個關鍵問題。
一、代碼角度
在頭文件中使用前置聲明，而不是直接包含頭文件。
不要以為你只是多加了一個頭文件，由於頭文件的"被包含"特性，這種效果可能會被無限放大。所以，要盡一切可能使頭文件精簡。很多時候前置申明某個namespace中的類會比較痛苦，而直接include會方便很多，千萬要抵制住這種誘惑；類的成員，函數參數等也盡量用引用，指針，為前置聲明創造條件。
使用Pimpl模式
Pimpl全稱為Private Implementation。傳統的C++的類的介面與實現是混淆在一起的，而Pimpl這種做法使得類的介面與實現得以完全分離。如此，只要類的公共介面保持不變，對類實現的修改始終只需編譯該cpp；同時，該類提供給外界的頭文件也會精簡許多。
高度模塊化
模塊化就是低耦合，就是盡可能的減少相互依賴。這里其實有兩個層面的意思。一是文件與文件之間，一個頭文件的變化，盡量不要引起其他文件的重新編譯；二是工程與工程之間，對一個工程的修改，盡量不要引起太多其他工程的編譯。這就要求頭文件，或者工程的內容一定要單一，不要什麼東西都往裡面塞，從而引起不必要的依賴。這也可以說是內聚性吧。
以頭文件為例，不要把兩個不相關的類，或者沒什麼聯系的宏定義放到一個頭文件里。內容要盡量單一，從而不會使包含他們的文件包含了不需要的內容。記得我們曾經做過這么一個事，把代碼中最"hot"的那些頭文件找出來，然後分成多個獨立的小文件，效果相當可觀。
其實我們去年做過的refactoring，把眾多DLL分離成UI與Core兩個部分，也是有著相同的效果的 - 提高開發效率。
刪除冗餘的頭文件
一些代碼經過上十年的開發與維護，經手的人無數，很有可能出現包含了沒用的頭文件，或重復包含的現象，去掉這些冗餘的include是相當必要的。當然，這主要是針對cpp的，因為對於一個頭文件，其中的某個include是否冗餘很難界定，得看是否在最終的編譯單元中用到了，而這樣又可能出現在一個編譯單元用到了，而在另外一個編譯單元中沒用到的情況。
之前曾寫過一個Perl腳本用來自動去除這些冗餘的頭文件，在某個工程中竟然去掉多達了5000多個的include。
特別注意inline和template
這是C++中兩種比較"先進"的機制，但是它們卻又強制我們在頭文件中包含實現，這對增加頭文件的內容，從而減慢編譯速度有著很大的貢獻。使用之前，權衡一下。
二、綜合技巧
預編譯頭文件（PCH）
把一些常用但不常改動的頭文件放在預編譯頭文件中。這樣，至少在單個工程中你不需要在每個編譯單元里一遍又一遍的load與解析同一個頭文件了。
Unity Build
Unity Build做法很簡單，把所有的cpp包含到一個cpp中(all.cpp) ,然後只編譯all.cpp。這樣我們就只有一個編譯單元，這意味著不需要重復load與解析同一個頭文件了，同時因為只產生一個obj文件，在鏈接的時候也不需要那麼密集的磁碟操作了,估計能有10x的提高，看看這個視頻感受一下其做法與速度吧。
ccache
compiler cache, 通過cache上一次編譯的結果，使rebuild在保持結果相同的情況下，極大的提高速度。我們知道如果是build，系統會對比源代碼與目標代碼的時間來決定是否要重新編譯某個文件，這個方法其實並不完全可靠(比如從svn上拿了上個版本的代碼)，而ccache判斷的原則則是文件的內容，相對來講要可靠的多。很可惜的是，Visual Studio現在還不支持這個功能 - 其實完全可以加一個新的命令，比如cache build，介於build與rebuild之間，這樣，rebuild就可以基本不用了。
不要有太多的Additional Include Directories
編譯器定位你include的頭文件，是根據你提供的include directories進行搜索的。可以想像，如果你提供了100個包含目錄，而某個頭文件是在第100個目錄下，定位它的過程是非常痛苦的。組織好你的包含目錄，並盡量保持簡潔。
三、編譯資源
要提高速度，要麼減少任務，要麼加派人手，前面兩個方面講得都是減少任務，而事實上，在提高編譯速度這塊，加派人手還是有著非常重要的作用的。
並行編譯
買個4核的，或者8核的cpu，每次一build，就是8個文件並行著編，那速度，看著都爽。 要是你們老闆不同意，讓他讀讀這篇文章：Hardware is Cheap, Programmers are Expensive
更好的磁碟
我們知道，編譯速度慢很大一部分原因是磁碟操作，那麼除了盡可能的減少磁碟操作，我們還可以做的就是加快磁碟速度。比如上面8個核一塊工作的時候，磁碟極有可能成為最大的瓶頸。買個15000轉的磁碟，或者SSD，或者RAID0的，總之，越快越好。
分布式編譯
一台機子的性能始終是有限的，利用網路中空閑的cpu資源，以及專門用來編譯的build server來幫助你編譯才能從根本上解決我們編譯速度的問題，想想原來要build 1個多小時工程的在2分鍾內就能搞定，你就知道你一定不能沒有它 - Incredibuild。
並行，其實還可以這么做。
這是一個比較極端的情況，如果你用了Incredibuild，對最終的編譯速度還是不滿意，怎麼辦？其實只要跳出思維的框架，編譯速度還是可以有質的飛躍的 - 前提是你有足夠多的機器：
假設你有solution A和solution B，B依賴於A，所以必須在A之後Build B。其中A，B Build各需要1個小時，那麼總共要2個小時。可是B一定要在A之後build嗎？跳出這個思維框架，你就有了下述方案：
這樣，通過讓A的build與B的編譯並行，最後link一下B中的project，整個編譯速度應該能夠控制在1個小時15分鍾之內。
同時開始build A和B 。
A的build成功，這里雖然B的build失敗了，但都只是失敗在最後的link上。
重新link B中的project。
⑥ 全新i5電腦，運行米思齊，每次編譯速度極慢，求解
第一就是你電腦中的垃圾，啟動項，進程，緩存，注冊表，一定是很久沒有清理了，由於這些東西太多，造成系統C盤太庸腫，特別是啟動項載入太多,所以開機的時候，就自然慢了，處理方法:就是下載一個騰訊電腦管家，安裝以後，你可以利用它經常清理這些垃圾，啟動項，進程，緩存，注冊表，而且它是智能的不會出錯的,特別是清理啟動項.(啟動項除cftmon都可以不用)
第二就是，你可能下載的什麼東西都放在C盤，造成C盤太多東西，負載太重，你可以冊除一些文件，把他安裝到其它盤符，以後要養成安裝軟體，程序，不要動不動就默認，而是要選擇安裝在其它盤符。騰訊電腦管家-工具箱-系統盤瘦身或軟體搬家，讓C盤輕裝上陣.
第三就是，IP地址，因為很多電腦用的是貓和路由器，而它的電腦選擇的是自動尋找IP，所以開機的時候，它在等路由器分給他一個IP，所以就有一個時間的等待，所以就慢了
⑦ C語言學習遇到瓶頸怎麼辦
1、沒有耐心學習了。畢竟C語言很抽象，學習起來很枯燥，能從頭學到尾的人確實不多。
2、遇到困難的知識點了。可能在指針那裡、鏈表那裡、數組那裡不理解了。這個也屬正常，C語言是抽象的，尤其在這幾個地方更加抽象。
3、寫不出代碼了。可能書是看完了，但是上手寫代碼，就寫不出來了，但是看別人的代碼又是可以看懂的。
如果題主的瓶頸期是第一個，這個我給不出啥建議。
如果題主的瓶頸期是第二個和第三個，我給出的建議是持之以恆。我想大家都聽說過1萬小時的理論。做任何一件事情，只要能投入至少1萬個小時，那麼你絕對是這個領域的專家。學習C語言也是，遇到困難了，可以查資料，可以問人，可以自己動手去實踐，反正要利用一切可以利用的資源，再加上自己的主動性，我相信沒有過不去的坎兒。題主有問題也可以跟我交流啊！
⑧ 感覺編程過程中遇到瓶頸了
過了入門級，那就需要多看範例了。多看別人的優質代碼，掌握別人解決問題的思路和方法，這樣才能提高的更快。至於大篇代碼看不懂，，不曉得你是真入門了，還是在門口晃悠。真入門了，那就是你思路不對，要從主類看起，分辨每一個函數的作用，然後再細看每一個函數是如何編寫的。要是還在門口晃悠，，那就沒法子了，補補基礎吧。
⑨ 淺談怎樣加快C++代碼的編譯速度
C++代碼一直以其運行時的高性能高調面對世人， 但是說起編譯速度，卻只有低調的份了。比如我現在工作的源代碼，哪怕使用Incredibuild調動近百台機子，一個完整的build也需要四個小時，恐怖！！！雖然平時開發一般不需要在本地做完整的build，但編譯幾個相關的工程就夠你等上好一段時間的了（老外管這個叫monkey around，相當形象）。想想若干年在一台單核2.8GHZ上工作時的場景 - 面前放本書，一點build按鈕，就低頭讀一會書~~~往事不堪回首。 可以想像，如果不加以重視，編譯速度極有可能會成為開發過程中的一個瓶頸。那麼，為什麼C++它就編譯的這么慢呢？ 我想最重要的一個原因應該是C++基本的「頭文件-源文件」的編譯模型： 1.每個源文件作為一個編譯單元，可能會包含上百甚至上千個頭文件，而在每一個編譯單元，這些頭文件都會被從硬碟讀進來一遍，然後被解析一遍。 2.每個編譯單元都會產生一個obj文件，然後所以這些obj文件會被link到一起，並且這個過程很難並行。 這里，問題在於無數頭文件的重復load與解析，以及密集的磁碟操作。 下面從各個角度給出一些加快編譯速度的做法，主要還是針對上面提出的這個關鍵問題。 一、代碼角度 1、在頭文件中使用前置聲明，而不是直接包含頭文件。 不要以為你只是多加了一個頭文件，由於頭文件的「被包含」特性，這種效果可能會被無限放大。所以，要盡一切可能使頭文件精簡。很多時候前置申明某個namespace中的類會比較痛苦，而直接include會方便很多，千萬要抵制住這種誘惑；類的成員，函數參數等也盡量用引用，指針，為前置聲明創造條件。 2、使用Pimpl模式 Pimpl全稱為Private Implementation。傳統的C++的類的介面與實現是混淆在一起的，而Pimpl這種做法使得類的介面與實現得以完全分離。如此，只要類的公共介面保持不變，對類實現的修改始終只需編譯該cpp；同時，該類提供給外界的頭文件也會精簡許多。 3、高度模塊化 模塊化就是低耦合，就是盡可能的減少相互依賴。這里其實有兩個層面的意思。一是文件與文件之間，一個頭文件的變化，盡量不要引起其他文件的重新編譯；二是工程與工程之間，對一個工程的修改，盡量不要引起太多其他工程的編譯。這就要求頭文件，或者工程的內容一定要單一，不要什麼東西都往裡面塞，從而引起不必要的依賴。這也可以說是內聚性吧。 以頭文件為例，不要把兩個不相關的類，或者沒什麼聯系的宏定義放到一個頭文件里。內容要盡量單一，從而不會使包含他們的文件包含了不需要的內容。記得我們曾經做過這么一個事，把代碼中最「hot」的那些頭文件找出來，然後分成多個獨立的小文件，效果相當可觀。 其實我們去年做過的refactoring，把眾多DLL分離成UI與Core兩個部分，也是有著相同的效果的 - 提高開發效率。 4、刪除冗餘的頭文件 一些代碼經過上十年的開發與維護，經手的人無數，很有可能出現包含了沒用的頭文件，或重復包含的現象，去掉這些冗餘的include是相當必要的。當然，這主要是針對cpp的，因為對於一個頭文件，其中的某個include是否冗餘很難界定，得看是否在最終的編譯單元中用到了，而這樣又可能出現在一個編譯單元用到了，而在另外一個編譯單元中沒用到的情況。 之前曾寫過一個Perl腳本用來自動去除這些冗餘的頭文件，在某個工程中竟然去掉多達了5000多個的include。 5、特別注意inline和template 這是C++中兩種比較「先進」的機制，但是它們卻又強制我們在頭文件中包含實現，這對增加頭文件的內容，從而減慢編譯速度有著很大的貢獻。使用之前，權衡一下。
⑩ android studio編譯時間長 中端電腦瓶頸是機械硬碟還是cpu 固態硬碟對速度提升大嗎
這個速度和機械硬碟的讀取速度有關，固態硬碟的寫入速度別HDD快多了，一般在70MB/S 以上吧