提高歸檔性能

Question

我有一個自動生成大量代碼的項目，我們在鏈接到最終可執行文件之前將其構建到靜態庫中。我們使用gcc /蚊蚋5.04a有這麼多的文件，我們必須將作業分成批次，調用AR多次以構建庫（爲了避免命令行長度的限制），例如：

[echo] Archiving codegen     
[echo] Deleting old codegen archive      
    [ar] Using ar found in /usr/bin   
    [ar] Batch 1 of 7 completed in 37.871 s 
    [ar] Batch 2 of 7 completed in 55.796 s 
    [ar] Batch 3 of 7 completed in 89.709 s 
    [ar] Batch 4 of 7 completed in 256.894 s 
    [ar] Batch 5 of 7 completed in 196.704 s 
    [ar] Batch 6 of 7 completed in 248.334 s 
    [ar] Batch 7 of 7 completed in 243.759 s 
    [ar] Archiving took: 1129.067 s   
    [ar] Using ranlib found in /usr/bin  
    [ar] Indexing took: 247.223 s    
[echo] Done with codegen     

我們正在尋找潛在的速度改進。看起來，隨着存檔的增長，每個批次需要的時間越來越長，大概是因爲它在添加對象之前有更多的搜索（用於更新）。這似乎是刪除歸檔文件比只更新舊歸檔文件更快的原因。在追求更高速度的過程中，我們在ar命令中使用了「qcS」標誌。根據手冊頁，「q」（它應該是快速附加的）實際上是「r」（它是「使用替換」）的同義詞，「c」創建存檔（沒有什麼特別的）和「S」跳過生成一個索引（我們在末尾再次使用「ranlib」覆蓋的索引

是否有任何方便的方式使用內置工具來使此操作更快？如果「快速附加」模式工作可能會是我們想要的，但唉

Answer 1

我們發現時間問題的一大部分是被歸檔文件的位置，上面的數字是位於NAS設備上的對象和歸檔文件。在本地硬盤上（臨時存儲）將時間減少到〜20 - 40秒。複製所有文件，執行本地存檔並複製結果需要很長時間而不是直接在NAS上進行存檔，但我們正在考慮將整個構建過程轉移到本地臨時存儲，這應該會大大提高性能。