最短編譯時間演算法

① 編譯程序所需要的時間和電腦的性能有關系么

有關系的
當需要編譯工程的復雜度一定的時候，電腦性能越好，編譯所需要時間越短；反之，則時間越長。
當電腦性能一定的時候，工程越復雜，則編譯所需要的時間越長；反之，則時間越短。

② i++是什麼意思

++i 和 i++在單獨使用時起到的作用就是 i=i+1，即後一個值是前一個值加一。

++i是使用i之前先使i加一。i++是使用i之後再加一。如果不能理解,那麼可以理解為：++i是先計算，再操作，i++是先操作，再計算。

例如：a = ++i，相當於 i=i+1; a = i; a = i++，相當於 a = i; i=i+1;

(2)最短編譯時間演算法擴展閱讀

「++」符號是編程語言中的自增運算符，作用是在運行後將變數的數值自動加一，「++」符號所處的位置不同，運算規則也不同，當「++」放在變數前方時，如 ++i,此時的作用是先將i變數中的數值進行加一運算，然後再將運算後的數值加入運算，而i++是先將i中的數值加入運算，然後再自加一。

i++的用法：

classYanShi{ publicstaticvoidmain(String[]args){ inti=3; i=i++; System.out.println("i="+i);}}//輸出是i=3

classYanShi_01

{ publicstaticvoidmain(String[]args){ inti=3,j; j=i++; System.out.println("i="+i+",j="+j);}}//輸出i=4,j=3

③ Xcode 構建速度優化（一）衡量編譯時間

隨著項目不斷迭代，工程文件越來越多，引用的三方庫也越來越多，這些直接導致編譯時間的不斷增加，完整編譯一次項目動輒需要五分鍾以上時間，實在有些影響開發效率，是時候來一波提速了。

為編譯和構建提速，首先我們需要對速度有一個衡量標准：准確獲得構建用時

首先，我們需要定義要衡量和優化的內容。 有兩種選擇：

xcode默認情況下會跟蹤所有構建，我們可以通過更改xcode相關設置，來在活動查看器中顯示出構建時間，通過命令行：

每次編譯成功後，會在Successed之後顯示出所用時間:

Xcode Build Timing Summary是Xcode10中加入的用於查看獲取構建時間和發現用時瓶頸方面的最有利工具。 可以通過Proct->Perform Action->Build With Timing Summary來開啟：這樣在 Build Log 的末尾就會添加 Timing Summary Log。我們可以通過這個 log 看到哪個階段是耗時的，便於我們進行優化。

如上圖中: xib階段的編譯耗時明顯是比普通c文件要多的，意味著我們可以通過減少xib方式來優化提升速度
而c文件的編譯用時比總時間還要長，是因為c文件是並行編譯的

在命令行中同樣可以開啟這個功能：

常用的第三方工具有 BuildTimeAnalyzer 、 xcode-build-times-rendering 、 XCLogParser 。

BuildTimeAnalyzer可以統計可以得出某個文件的類型檢查時長，每個表達式的類型檢查時長。

xcode-build-times-rendering是一個Ruby編寫的第三方工具，可以方便地分別測量目標的構建時間並在圖表上顯示它們，使用gem安裝

接下來使用這個工具自帶命令配置項目

然後構建項目並生成報告：

這個工具使用上比較簡單，缺點是只能從宏觀上生成各個target編譯的整體圖標，無法詳細列出各個內部編譯明細

XCLogParser可以詳細列出各個Target和內部每個文件的編譯耗時，對我們分析編譯時間瓶頸非常有幫助，它的工作原理主要是做為解析器，通過解析xcode編譯生成的xcactivitylog日誌來記錄
安裝：

編譯項目後，進行安裝

安裝成功後通過命令：

會自動在當前目錄的 build/xclogparser/reports/ 路徑下生成報告，其中--project參數需要設置為待分析項目的名字，並注意當前在終端切換到希望寫入日誌的目錄。

報告截圖：

這個工具將作為我們後面分析提升編譯構建速度的主要使用工具。

經過我多次在不同時間段，不同電腦上不斷嘗試編譯，
我發現編譯耗時是一個比較玄的東西，及時在同一台電腦，同一個項目， 同一套環境配置下，編譯用時也會隨著電腦當前狀態（包括同時打開進程、散熱等等）上下大幅跳動，就像演算法時間復雜度一樣，有時候我們明明做了一些細微的優化，但是結果反而是編譯耗時增加了，這是很正常的事情
所以，衡量這個標准需要我們取多次試驗中的平均值作為參考。

④ 影響演算法執行時間的因素主要有哪些

影響演算法執行時間的因素包括：

1、演算法本身選用的策略；

2、問題的規模；

3、書寫程序的語言；

4、編譯產生的機器代碼質量；

5、機器執行指令的速度等。

為便於比較演算法本身的優劣，應排除其它影響演算法效率的因素。從演算法中選取一種對於所研究的問題來說是基本操作的原操作，以該基本操作重復執行的次數作為演算法的時間量。

(4)最短編譯時間演算法擴展閱讀：

縮短演算法時間的方法：

1、選擇合理的存儲結構。

數據的存儲結構，分為順序存儲結構和鏈式存儲結構。順序存儲結構的特點是藉助元素在存儲器中的相對位置來表示數據元素之間的邏輯關系；鏈式存儲結構則神豎握是藉助指示元素存儲地址纖搭的指針表示數據元素之間的邏輯關系。

2、使用直接初始化。游慶

與直接初始化對應的是復制初始化。

3、減少除法運算的使用。

無論是整數還是浮點數運算，除法都是一件運算速度很慢的指令，在計算機中實現除法是比較復雜的。所以要減少除法運算的次數。

⑤ C語言多充循環，運算次數多，編譯時間很長，又無法估計最終需要多久，怎麼辦

如果要減少時間 那麼優化代碼，或者直接改進演算法
如果要預測時間，那麼大致估計一下循環的次數，然後在固定的某個循環中加一個列印，通過列印頻率來估算總時間

⑥ python編譯時間長

沒有尾遞歸優化。
因為某些編譯型語言（如C）的編譯器有尾遞歸優化，所以遞歸演算法效率並不低。但是python並沒有尾遞歸優化。
Python是一種廣泛使用的解釋型、高級和通用的編程語言。[1]Python由荷蘭數學和計算機科學研究學會的GuidovanRossum創造，第一版發布於1991年，它是ABC語言的後繼者，也可以視之為一種使用傳統中綴表達式的LISP方言。

⑦ 我應該買什麼ＰＣ來獲取Quartus II的最快速編譯時間

最後修改: 2012 年9 月05 日
產品類別: 設計軟體
產品領域: 安裝/授權(設計軟體)
產品子領域: 操作系統支持/系統要求
標題說明Altera為Quartus03 II 只推薦最低硬體要求，最低可用物理RAM，和交換空間。這些推薦是在載有Quartus II的readme.txt格式中和在器件支持版本注釋中，存在於Quartus II Development Software documentation page最低要求使Quartus II 能夠運行。如果您具有大的設計和想要最佳編譯時間，Altera建議更高的配置。 Quartus II需要大量的處理器和存儲器資源。CPU速度是影響編譯次數性能的主要因素。請考慮多核處理器和多CPU的配置，從而利用多線程編譯。使用分化快設計和增量式編譯來完全利用可用內核。請參考 Quartus II手冊的第二卷的Recing Compilation Time章節。除此之外，解決以下三個瓶頸：通過處理器最大化晶元上的緩存訪問最小化虛擬儲存器的使用最小化硬碟訪問時間通過處理器最大化晶元上的緩存訪問選擇具有大量的晶元上緩存的CPU。最小化虛擬儲存的使用使用64-位體系結構和操作系統，伴隨足夠量的快速速度等級RAM。隨著器件大小和軟體復雜性的增長，內存使用也在增加。針對較新的器件系列(Stratix03 III 和更新的版本)的設計比用於32位應用的RAM的2GB需要更多，所以使用64位操作系統和軟體。對於一個64位系統，對於更大的器件系列，一個單編譯應該已經訪問至少RAM的8GB (安裝8到10GB)和更多。對於每種器件的最低安裝的RAM信息，請參考器件支持版本注釋，存在於Quartus II Development Software documentation page。最短的硬碟訪問時間使用快速或固態硬碟安裝一個本地SCSI或基於SATA的體系結構。磁碟也可以被RAID條帶化，以便更快的訪問。 使用網路磁碟可以是編譯時間的一個顯著地瓶頸。如果您必須在網路硬碟上存儲工程源，Altera建議使用網路文件系統的源文件創建一個本地工程，保持項目目錄當地和源文件遠程。Quartus II 只讀取幾次源文件，但是需要訪問Quartus II資料庫(db and incremental_db)很多次。補充注釋從32位轉換到64位 OS並且軟體可能不會減少編譯時間。64位Quartus II使能夠訪問每進程較大的儲存映射(沒有2GB限制),但是使用64位OS或軟體時可能看不到提高，如果我們的設計沒有達到2GB限制並且在32位OS上使用低虛擬儲存。您可能看到編譯次數的稍微降低，由於64位進程的較多開銷。Quartus II 10.0的編譯次數性能和更新的64位對比32位(64位機上)是可比較的，如同Windows OS的性能對比相等的Linux (32位對比32位，或者64位對比64位)。

⑧ 程序的編譯速度與程序的執行速度

執行與編譯。。也有掛鉤！。。執行、編譯速度又跟硬體有關！用 WEB來說 第一次編譯比較慢！後面這次訪問就快多了！這跟緩存有關。。還有就是代碼的問題。。 多次的循環判斷也會造成系統執行變慢！。。在提升速度方面 主要就是倆種方法 1.完善的代碼 2.提高硬體了！可能我說的比較片面！別的兄弟可以繼續補充！

⑨ 編譯速度最慢的是 C++ 嗎

編譯察慧散速度一般取決機器和編譯時的解析代碼演算法，其次取決代碼量，如碧兆果代碼有庫的話，使用庫而少量代碼作敗氏為本地編譯的話，速度會非常快，但是本地代碼大於庫代碼量的時候，略顯難度