Практическое руководство отлаживает (медленного) компоновщика в debian системе
Если вам не нравится идея «отменить возврат» (особенно, когда это означает потерю хронологической информации для многих коммитов), вы всегда можете обратиться к документации git о «Возврат ошибочного слияния» .
Учитывая следующую исходную ситуацию
P---o---o---M---x---x---W---x
\ /
A---B---C----------------D---E <-- fixed-up topic branch
(W - ваш начальный возврат слияния M; D и E - исправления к вашей изначально поврежденной ветви / коммиту)
Вы можете теперь просто воспроизводим коммиты от A до E, так что ни один из них не «принадлежит» к обратному слиянию:
$ git checkout E
$ git rebase --no-ff P
Новая копия вашей ветви теперь может быть снова объединена с master:
A'---B'---C'------------D'---E' <-- recreated topic branch
/
P---o---o---M---x---x---W---x
\ /
A---B---C----------------D---E
4 ответа
Если вы наблюдаете замедление работы gcc (в отличие от прямого запуска компоновщика как ld ), попробуйте скомпилировать с помощью
$ gcc -save-temps -v [... rest of your command line ...]
. Это распечатает все промежуточные команды, такие как внутренний collect2 и final ld , а также гарантируют, что объекты, переданные этим командам, останутся на диске даже после выполнения команды.
Затем вы сможете запускать команды по отдельности, чтобы найти худший этап, а затем запускать его с другими параметрами или профилированием.
Чтобы ответить на вопрос профилирования; вам следует взглянуть на OProfile - это профилировщик системного уровня, который может профилировать несколько запущенных процессов. Он должен позволить вам определить, какой подпроцесс ссылки занимает больше всего времени, и, кроме того, покажет, на какие функции уходит больше всего времени.
Вы можете попробовать золото ( binutils-gold ) вместо ld .
Предполагается, что это будет быстрее.
Вот цитата из Wikipedia Gold (компоновщик)
Мотивация для написания золота заключалась в том, чтобы сделать компоновщик быстрее, чем Компоновщик GNU [3], особенно для больших applications coded in C++.
The author of gold (Ian Lance Taylor) has published an (longish) article about linkers where he explains his motifs in writing gold and why most linkers are slow. If you are interested in the inner workings of linkers this article is worth reading.
Я хотел бы предложить два способа проверки:
- используйте strace, чтобы проверить, какие файлы компоновщик загружает / анализирует для связывания; с этим вы можете узнать, ищет ли компоновщик ненужный путь.
- используйте ld с опцией -verbose, чтобы узнать, что делает ld. Сравнение пяти минут с пятью секундами не должно быть проблемой компоновщика, это должна быть проблема вашего хост-компьютера или какой-либо опции.