Повышение производительности ar-архивирования

Question

У меня есть проект с огромным количеством автоматически сгенерированного кода, который мы встраиваем в статическую библиотеку перед тем, как связать с конечным исполняемым файлом.Мы используем 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                   

Мы ищем потенциальные улучшения скорости.Похоже, что по мере роста архива каждый пакет занимает все больше и больше времени, предположительно потому, что в нем больше возможностей для поиска (обновлений) перед добавлением объектов.По-видимому, именно поэтому удаление архива делает это быстрее, чем просто обновление старого архива на месте.В нашем стремлении к большей скорости мы используем флаги "qcS" для команды ar.Согласно справочной странице, "q" (который должен быть быстро добавлен) на самом деле является синонимом "r" (который означает "использовать замену"), "c" создает архив (там ничего особенного), а "S" пропускает генерацию индекса (который мы покрываем, снова используя "ranlib" в конце.

Есть ли какой-нибудь удобный способ, используя встроенные инструменты, ускорить эту операцию?Если бы режим "быстрого добавления" работал, это, вероятно, было бы тем, чего мы хотим, но, увы.

Answer 1

Мы обнаружили, что огромная часть проблемы со сроками была связана с расположением архивируемых файлов.Приведенные выше цифры относятся к объектным и архивным файлам, расположенным на устройстве NAS.Выполнение той же операции на локальном жестком диске (временном хранилище) сокращает время до ~ 20-40 секунд.Копирование всех файлов, выполнение локального архивирования и копирование результата обратно занимает больше времени, чем архивирование непосредственно на NAS, но мы рассматриваем возможность переноса всего процесса сборки в локальное временное хранилище, что должно существенно повысить производительность.