1

我有一个包含大量自动生成代码的项目，我们在链接到最终可执行文件之前将其构建到静态库中。我们使用 gcc/gnat 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”来覆盖它。

有没有什么方便的方法，使用内置工具，让这个操作更快？如果“快速附加”模式有效，那可能就是我们想要的，但是唉。

4

1 回答 1

1

我们发现时间问题的很大一部分是归档文件的位置。上面的数字适用于位于 NAS 设备上的对象和存档文件。在本地硬盘（临时存储）上执行相同的操作可将时间减少到约 20 - 40 秒。复制所有文件、进行本地存档并将结果复制回来比直接在 NAS 上存档需要更长的时间，但我们正在考虑将整个构建过程转移到本地临时存储，这将大大提高性能。

于 2010-01-11T14:58:54.783 回答