我有一个巨大的自动生成的代码量,我们链接到最终的可执行文件之前建设成为一个静态库的项目。我们使用gcc /蚊蚋5.04a有这么多的文件,我们必须将作业分成批次,调用AR多次以构建库(为了避免命令行长度的限制),e.g:

 [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                   

我们正在寻找潜在的速度改进。看来,作为存档的增长,每批需要更长的时间越来越长,大概是因为它有更多的加入对象之前搜索(更新)。这似乎可以解释为什么删除归档使得它比刚刚更新旧档案的地方更快。在我们针对速度的追求,我们用标志“QCS”的ar命令。根据该男子页,“Q”(这应该是快速的append)是真正为“R”(这是“使用替换”)的代名词,“C”创建存档(没有什么特别的存在)和“S”跳过在端部产生的索引(我们通过使用覆盖“RANLIB”一次。

是否有任何方便的方式,使用内置的工具,以使该操作更快?如果“快速追加”模式工作,那真的是我们想要的,但很可惜。

有帮助吗?

解决方案

我们发现,计时问题的很大一部分是被归档的文件的位置。上面的数字是位于NAS设备上的对象和归档文件。做一个本地硬盘(临时存储)在相同的操作减少的时间〜20 - 40秒。复制所有文件,做本地存档,并复制结果返回时间比直接在NAS归档更长的时间,但我们正在考虑把我们的整个构建过程到本地临时存储,应大幅提高性能。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top