Работа ccache

стоит ccache, в make.conf прописано

 CC=gcc
CXX=g++
CCACHE_SIZE="2G"
FEATURES="ccache

однако при переустановке xulrunner было замечено, что никакого убыстрения не идет
в emerge --info

version 2.4 [enabled]
dev-util/ccache:     2.4-r8
FEATURES="assume-digests ccache...

┌┌(ra@taaroa)┌(264/pts/2)┌(12

┌┌(ra@taaroa)┌(264/pts/2)┌(12:48:03/06/10)┌-
└┌(%:~)┌- grep CCACHE /etc/make.conf
CCACHE_SIZE="5G"
CCACHE_DIR="/var/tmp/ccache"
┌┌(ra@taaroa)┌(265/pts/2)┌(12:53:03/06/10)┌-
└┌(%:~)┌- grep ccache /etc/env.d/00basic 
PATH="/usr/lib64/ccache/bin:/opt/bin"
┌┌(ra@taaroa)┌(266/pts/2)┌(12:54:03/06/10)┌-
└┌(%:~)┌- CCACHE_DIR="/var/tmp/ccache" ccache -s
cache directory                     /var/tmp/ccache
cache hit                         167617
cache miss                        351186
called for link                    33676
multiple source files                 31
compile failed                     13857
ccache internal error                 38
preprocessor error                  4651
not a C/C++ file                   28367
autoconf compile/link              61902
unsupported compiler option        27280
no input file                      28381
files in cache                    205744
cache size                           4.4 Gbytes
max cache size                       5.0 Gbytes

Ну, если вас не устраивает работа ccache, то просто не используйте.

P.S. а еще лучше просто внимательно прочитать|перечитать _как_ его настраивать и как оно работает.

а что может устраивать, если

а что может устраивать, если место занимается, а пользы никакой? У меня то же самое показывается, толку от этого только нет. Что я не так использую, что нужно перечитать?

Место?

При нонешних дисковых объёмах место, занимаемое ccache - капля пива
в кружке с водкой :D
Вот если Вы перенесёте /var и /ccache на другой физический диск, то в производительности
только выиграете.

Еще раз: taaroa

Еще раз:

taaroa написал(а):
Ну, если вас не устраивает работа ccache, то просто не используйте.

aes78 написал(а):
а что может устраивать, если место занимается, а пользы никакой? У меня то же самое показывается, толку от этого только нет.

Смотрим выше, повторяем как мантру: я осознаю то что я делаю, за все что я делаю, отвечаю только я.

taaroa, зачем писать ненужные

taaroa, зачем писать ненужные сообщения? Если нечего сказать, лучше промолчать. ccache должен ускорять обновление как заявлено в 5-10 раз, а он не ускоряет, мне не нужно никуда ничего переносить. Я согласен,что место небольшое, но зачем я буду его занимать, если программа не выполняет своего назначения?

aes78 написал(а): taaroa,

aes78 написал(а):
taaroa, зачем писать ненужные сообщения? Если нечего сказать, лучше промолчать.

Это модераторам решать, что есть нужные сообщения, а что есть флэйм, хорошо?
Свою точку зрения озвучил выше.

aes78 написал(а):
Если нечего сказать, лучше промолчать.

Можно мне все таки самому решать, что и где писать и насколько оно полезно? Можно?

aes78 написал(а):
ccache должен ускорять обновление как заявлено в 5-10 раз

Ccache не поможет при _обновлении_, он помогает при перекомпиляции. Ccache вам ничего не должен, и вообще это _быстрый_кэш_компилятора_, такие дела. Ccache - это кэширующий препроцессор - для каждого файла вычисляется хэш, на основании которого в последствии можно определить уже скомпилированный файл, - это дает серьезный прирост в скорости на 2 и последующих сборках.

aes78 написал(а):
но зачем я буду его занимать, если программа не выполняет своего назначения?

Ну если вы так считаете, то напишу еще раз: не используйте ccache.
Меня его работа устраивает.

Нельзя. Вы сами себе

Нельзя. Вы сами себе противоречите.

Зачем?

Давай те хоть я поблагодарю вас за развернутый верный ответ, но бисер вы мечете имхо совершенно напрасно?
Он не хочет знать про ccache, он все давно для себя решил, просто ему наверно поговорить не с кем :)

Вы знаете, как то так

Вы знаете, как то так получилось, что этот развернутый ответ я уже давно знаю, и я не его спрашивал. На форуме слишком много самоуверенных ничего из себя не представляющих людей, которые мало того, что ничего не знают сами, так еще и других поучать пытаются.

Тем не менее он прав. ccache

Тем не менее он прав.
ccache помогает далеко не всегда. Он может не быть задействованным даже при пересборке, а не обновлении пакета (мне кажется, это если обновились зависимости, например).

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

aes78 написал(а):Вы знаете,

aes78 написал(а):
Вы знаете, как то так получилось, что этот развернутый ответ я уже давно знаю, и я не его спрашивал.

А вот совсем не похоже на то. Я скажу даже больше - ccache на первой сборке пакета местами ощутимо её замедляет, бывает приводит к ошибкам сборки, и иногда приводит к смерти домашних животных. После проблем со сборкой icedtea я его удалил, хотя мне он помогал весьма сильно - я использую полторы сотни live-пакетов сборку которых он серьёзно ускорял, в 2-3 раза, к тому же я эти пакеты по статистике, в среднем раз в 3 дня — неделю пересобираю... Если же тебе действительно хочется что-то узнать, почитай http://blog.flameeyes.eu/2008/06/21/debuking-ccache-myths возможно перестанешь нести чушь.

aes78 написал(а):
На форуме слишком много самоуверенных ничего из себя не представляющих людей, которые мало того, что ничего не знают сами, так еще и других поучать пытаются.

Может тогда воспользоваться платной техподдержкой ? Или нанять грамотных специалистов для обучения? А то получается что люди пробуют помочь а их обзывают «тупыми упырями» и сетуют на то что «я всё и без вас знаю», в тоже время не можешь нормально сообщить об ошибке. Нехорошо.

Об ошибке нормально сообщено,

Об ошибке нормально сообщено, со всеми необходимыми приложениями.

aes78 написал(а): Об ошибке

aes78 написал(а):
Об ошибке нормально сообщено, со всеми необходимыми приложениями.

Это твое личное мнение, никто тебя в этом не собирается переубеждать, пока сам не захочеш.
Почему-то мнение большинства отличное от твоего.
Я к примеру и ошибки то не увидел в твоем посте.
Так что думать-думать и думать прежде чем писать.

Мнение большинства всегда

Мнение большинства всегда ошибочно, поэтому я не увижу. Ошибки в моем посте нет, я спрашивал, почему ccache не действует так, как заявлено.

:)

Да откуда вы знаете что ccache не действует так как должно?
Я же говорю - это ваше личное субьективное мнение.
Где вы указали измерения времени сборки без ccache, затем с ним, но с его пустым кешем,
потом время сборки того же приложения повторно, и т.д.
Так что я повторю - ваш стартовый топик больше похож на мысли вслух, но ни как на
конкретное описание какой-то ошибки. И вопроса нет в стартовом посте.
Так, просто поговорить нескем было, вот и написали о ccashe.

Что такое ccache? ccache -

Что такое ccache? ccache - это быстрый кэш компилятора. Временные файлы, которые будут созданы во время компиляции программы будут закэшированы, в результате чего во время обновления установленного программного обеспечения, время , затраченное на компиляцию программного значительно cокращается.
Из handbook:

Цитата:
ccache — это быстрый кэш компилятора. Когда вы компилируете программу, он кэширует промежуточные результаты так, что всякий раз, когда вы перекомпилируете ту же самую программу, время компиляции значительно сокращается. В типичных случаях общее время компиляции может сокращаться в 5—10 раз.

А то, что вопроса нет - это ясно видно из того, что приводится в первом посте и почитав форум я понял, что вопросы здесь не очень принято задавать, все идет к краткости. 5-10 раз для xulrunner не нужно замерять, это было бы видно невооруженным глазом.

aes78 написал(а): Что такое

aes78 написал(а):
Что такое ccache? ccache - это быстрый кэш компилятора. Временные файлы, которые будут созданы во время компиляции программы будут закэшированы, в результате чего во время обновления установленного программного обеспечения, время , затраченное на компиляцию программного значительно cокращается.

И тут же вы приводите выдержку из handbook

aes78 написал(а):
Из handbook:
Цитата:
ccache — это быстрый кэш компилятора. Когда вы компилируете программу, он кэширует промежуточные результаты так, что всякий раз, когда вы перекомпилируете ту же самую программу, время компиляции значительно сокращается. В типичных случаях общее время компиляции может сокращаться в 5—10 раз.

Чем фактически подтверждаете - что абсолютно не поняли суть вопроса.

aes78 написал(а):
А то, что вопроса нет - это ясно видно из того, что приводится в первом посте и почитав форум я понял, что вопросы здесь не очень принято задавать, все идет к краткости. 5-10 раз для xulrunner не нужно замерять, это было бы видно невооруженным глазом.

Невооруженный глаз - офигенный инструмент диагностики, не спорю. :)
Вот если бы вы показали настройки свои и время сборки того же xulrunner в различных режимах, как я указал в посте выше - тогда есть о чем говорить, а так
я подчеркиваю - ваш топик - разговор ни о чем, просто мысли вслух человека, который не разобрался в сути происходящего.

В общем я понял, что никто

В общем я понял, что никто ничего конкретного сказать не может, а разговоры о том, что я не вник в суть вопроса ни к чему, поскольку я в суть вопроса как раз таки вник. Мне ccache нужен только для того, чтобы время обновления программ сократить и ни для чего больше. xulrunner собирается около 2 часов, если он начнет даже собираться 1 час 30 минут - это мне ничего не даст. Мне не интересно сокращение на минуты. Мой топик был направлен на то, чтобы выяснить у людей, которые давно в генту - может быть у меня где-то в конфигах ошибки, может еще что-то нужно указать, может быть я работаю не в типичных, а в экстремальных условиях и т.д., но идут просто сплошные оскорбления.

Да всё было сказано сразу,

Да всё было сказано сразу, только не надо было считать себя самым умным и внимательно читать.

 % qlop -tgH qt-creator 
qt-creator: Fri Jan 29 13:17:44 2010: 10 minutes, 59 seconds
qt-creator: Sat Feb  6 00:42:55 2010: 7 minutes, 53 seconds
qt-creator: Tue Mar  2 11:52:55 2010: 9 minutes, 15 seconds
qt-creator: Sun Mar  7 17:58:19 2010: 1 minute, 44 seconds

Это вот ускорение из-за ccache, познакомьтесь.

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

krigstask написал(а):Да всё

krigstask написал(а):
Да всё было сказано сразу, только не надо было считать себя самым умным и внимательно читать.

 % qlop -tgH qt-creator 
qt-creator: Fri Jan 29 13:17:44 2010: 10 minutes, 59 seconds
qt-creator: Sat Feb  6 00:42:55 2010: 7 minutes, 53 seconds
qt-creator: Tue Mar  2 11:52:55 2010: 9 minutes, 15 seconds
qt-creator: Sun Mar  7 17:58:19 2010: 1 minute, 44 seconds

Это вот ускорение из-за ccache, познакомьтесь.

Это, конечно, интересно для ознакомления, но меня больше интересует почему у меня xulrunner после неоднократных пересборок не дал никакого ускорения.
Я себя не считаю самым умным, но вы путаете ум и разум, а это есть суть две разные вещи. Знание не порождает ум, но это ближе к философии. И что было сказано с самого начала? С самого начала было сказано, что если не нравится - не пользуйтесь. Я бы не пользовался, если бы я знал альтернативу по сокращению времени компиляции или если бы в бинарных дистрибутивах перестали насаждать policykit и pulseaudio.

2SysA:
http://gentoo.ru/philosophy

Aga, eto my uze proxodili, -

Aga, eto my uze proxodili, - "...ves vzvod ne v nogu, tolko startsina v nogu!".
Scastlivo ostavatsja s vasimi zabluzdenijami...

BTW: Linus kak-to skazal v interv'ju BBC, cto na svete 99% durakov, a Linux prednaznacen dlja ostavsegosja 1%. Ot sebja ja mogu dobavit, cto Gentoo dlja esce bolee uzkoj auditorii, vozmozno tot ze 1% ot vsex linuxoidov, poskolku Linux sam po sebe trebuet osmyslenija svoix dejstvij, a Gentoo - tem bolee...

:)

aes78, специально чтоб тебе доказать что ccache все-таки работает, и при том работает точно так как указано в handbook,
а не так как тебе хочется, судя из твоего поста - снес у себя его кеш. :(

Вот последовательность действий и их результаты.

Очищаем кеш компилятора, дабы никак не влиял на наши измерения.

# rm -rf /var/tmp/ccache/*

Запускаем сборку без ccache - вывод ее здесь и далее направляем в /dev/null, дабы не влиял тормоз в виде вывода на консоль.

# time FEATURES="-ccache" emerge -B xulrunner  > /dev/null 2> &1

real    9m12.319s
user    18m59.914s
sys     3m1.248s

Теперь сборка с ccache - должна немного медленней быть, так как надо время на наполнение его кеша.

# time FEATURES="ccache" emerge -B xulrunner > /dev/null 2>&1

real    9m16.857s
user    19m43.233s
sys     3m26.392s

И опять сборка того же пакета - но с заполненным кешем компилятора.

# time FEATURES="ccache" emerge -B xulrunner > /dev/null 2>&1

real    3m42.203s
user    3m43.463s
sys     2m11.609s

И после этого вы продолжите утверждать что незаметно результатов? Почти в 3 раза быстрее - это незаметно? Ого... плохой у вас инструмент под именем глаз. :)
Если у вас их все-таки незаметно - так телепаты в весеннем отпуске, конфиги ваши и результаты измерений сборки никто так и не увидел.
Какие еще могут быть вопросы?
Желаете получить полный исчерпывающий ответ - задайте правильно вопрос - в нем сами сможете обнаружить 50% ответа.

Я вам могу точно сказать, что

Я вам могу точно сказать, что ни в одном правильно заданном вопросе вы не увидите и 10% ответа. Последую вашим рекомендациям месяца через два, когда буду обновляться, а сейчас часовые пересборки для тестирования мне ни к чему

aes78 написал(а): месяца

aes78 написал(а):
месяца через два, когда буду обновляться

Да нихрена вы не поняли, судя по этому.
Перечитайте внимательно что сами писали и что я выделил в ваших цитатах, если не поймете - тогда уж извините, помочь нечем.

Сойдемся на том, что я

Сойдемся на том, что я безнадежен.

не совсем верно

Ключевые слова - "перекомпилируете ту же самую программу", "в типичных случаях", "может сокращаться".
Иными словами - эффект возможен только при повторной сборке некоей одной и той же программы.
И, опять же - в "типичных" случаях. Как правило это относится к целиком сишным/плюсовым проектам. Если программа большей частью на других языках программирования - ccache отступает.
Или, к примеру, если сборка включает генерацию/модификацию исходников прямо в процессе. Например - вставляет в какой-нибудь всеобщий хедер дату и время сборки. В этом случае все файлы, куда будет включён этот хедер, уже не попадут под ccache из-за изменений.
Поэтому - время может сокращаться, а может и нет.
Никаких гарантий и обещаний по этому поводу не даётся.
И поэтому по меньшей мере глупо предъявлять претензии по поводу отсутствия ускорения в каком-то конкретном проекте.
Если бы в хэндбуке было бы прямо написано, что ccache ускоряет сборку xulrunner в 10 раз - это был бы другой разговор.

Ваше объяснение

Ваше объяснение представляется мне более целесообразным, однако я никаких претензий не предъявляю, достаточно глупо предъявлять претензии по СПО, где никто никому ничего не должен. Я это пытался выяснить для себя, а не для того, чтобы предъявить какие-то претензии. xulrunner - это одна и та же программа перекомпилируется или вы имеете в виду одну и ту же версию программы (но об этом нигде ничего не сказано), собственно, она занимает одно из наибольших единиц времени компиляции, и лично для меня, если у нее время компиляции не уменьшается, смысла в ccache особого нет (возможно, что на других сильнокомпилирующихся пакетах будет, но другие пакеты еще не прошли всю цепочку, поэтому я ничего сказать не могу, а тратить сейчас время на перекомпиляцию таких сильнозатратных по времени программ я не могу).

Ну... что ж вы хотите... Это

Ну... что ж вы хотите... Это source-based дистрибутив. Будьте готовы к многочасовым компиляциям.
ЗЫ: я обычно разные emerge -uDN @system @world запускаю на выходные. + пользуюсь distcc и помощью простаивающих в сети компов (это РЕАЛЬНО ускоряет сборку).

Я понимаю, что это

Я понимаю, что это source-based и хотелось бы облегчить участь многочасовых компиляций. У меня знакомый за два часа с помощью ccache обновляет мир, у меня последний раз ушло на обновление мира 37 часов. У меня сети нет и простаивающих в ней компов то же. Моя работа требует практически постоянной работы на компьютере. Если же включен ccache, то CPU занято процентов на 40-50, что делает неудобной работу в других приложениях.

Цитата:
там ведутся такие-же разговоры — с непробиваемым апломбом, закидывая странными аргументами и ссылаясь на не менее странные авторитеты пишутся не совсем вменяемые посты.

Я допускаю, что вам по молодости лет логичные доводы кажутся непробиваемым апломбом, нормальные аргументы странными, те авторитеты, которые вам не нравятся и посты, которые вы не поняли - странными. Поверьте, они таковыми не являются.
При том, что я довольно сносно владею английским языком, мой родной язык - русский, компьютер мне нужен для работы, а не для того, чтобы сидеть и изучать различные английские статьи, которые не относятся напрямую к моей работе. С учетом того, что есть русскоязычное сообщество генту, я предпочел спросить там, и я бы назвал странным то, что на русскоязычном ресурсе отсылают к англоязычным.

aes78

aes78 написал(а):
Цитата:
там ведутся такие-же разговоры — с непробиваемым апломбом, закидывая странными аргументами и ссылаясь на не менее странные авторитеты пишутся не совсем вменяемые посты.

Я допускаю, что вам по молодости лет логичные доводы кажутся непробиваемым апломбом, нормальные аргументы странными, те авторитеты, которые вам не нравятся и посты, которые вы не поняли - странными. Поверьте, они таковыми не являются.

Дело не в том что какие-то посты мне нравятся а какие-то нет, или я что-то не понял.

aes78 написал(а):
При том, что я довольно сносно владею английским языком, мой родной язык - русский, компьютер мне нужен для работы, а не для того, чтобы сидеть и изучать различные английские статьи, которые не относятся напрямую к моей работе. С учетом того, что есть русскоязычное сообщество генту, я предпочел спросить там, и я бы назвал странным то, что на русскоязычном ресурсе отсылают к англоязычным.

А тебе не кажется странным то, что Диего, который итальянец, пишет на английском, который тоже не очень хорошо знает?

aes78 написал(а):Об ошибке

aes78 написал(а):
Об ошибке нормально сообщено, со всеми необходимыми приложениями.

Возможно, тут есть и моя проблема - перед тем как писать ответ я почитал твои сообщения в других темах, там ведутся такие-же разговоры — с непробиваемым апломбом, закидывая странными аргументами и ссылаясь на не менее странные авторитеты пишутся не совсем вменяемые посты.
В этой теме нет сообщения о ошибке, но с твоей точки зрения поведение пакета некорректно. С одной стороны есть заявления о том что ты знаешь как работает ccache но на практике «невооружённым взглядом» видно что нет. Я даже оставил ссылку на запись в блоге одного из разработчиков gentoo который так и называется - «мифы о ccache» но он похоже прочитан не был, а заявления и апломб — остались.
Когда говорят что кэш помогает собирать одну и туже программу то то имеется в виду то, что собирается ровно один и тот-же код, ведь компилятор имеет дело с отдельными файлами исходников а не с некими абстрактными «программами» и вот каждый такой кусочек он сохраняет и кэширует. А далее появляется некое соревнование - что быстрее:
собрать кусочек кода
найти результат сборки на диске
Также есть усложнение в плане самих кусочков кода - в больших проектах их тысячи, и какаято часть вполне может остаться неизменной на разных версиях программы, и таких тонкостей хватает. Для меня гораздо больший прирост в скорости дало перемещение сборочного каталога в ОЗУ. Но с какой стати я буду переписывать то что до меня написал Диего?

После прочтения трэда всё же

После прочтения трэда всё же понятно что вы недопоняли как работает ccache или хотите чтобы он работал там где он работать не должен.
Тесты специально для вас:

1я компиляция xulrunner-1.9.2-r4:

# ccache -s
cache directory                     /var/tmp/ccache
cache hit                              7
cache miss                          2164
called for link                       27
compile failed                        17
preprocessor error                     1
not a C/C++ file                      10
autoconf compile/link                102
unsupported compiler option            4
no input file                         29
files in cache                      4328
cache size                          64.8 Mbytes
max cache size                       2.0 Gbytes

2я компиляция xulrunner-1.9.2-r4:

# ccache -s
cache directory                     /var/tmp/ccache
cache hit                           2176
cache miss                          2166
called for link                       54
compile failed                        34
preprocessor error                     2
not a C/C++ file                      20
autoconf compile/link                204
unsupported compiler option            8
no input file                         58
files in cache                      4332
cache size                          64.9 Mbytes
max cache size                       2.0 Gbytes
# qlop -vtgH xulrunner
xulrunner-1.9.2-r4: Sun Mar  7 23:02:10 2010: 15 minutes, 44 seconds (без ccache + скачивание 45мб тарбола)
xulrunner-1.9.2-r4: Sun Mar  7 23:24:21 2010: 14 minutes, 1 second (ccache пустой)
xulrunner-1.9.2-r4: Sun Mar  7 23:38:05 2010: 4 minutes, 44 seconds (ccache)
xulrunner: 3 times

Откомпилированые файлы брались из кэша, по md5 хэшу прекомпиленого файла - поэтому при пересборке оно ускоряется, а при обновлении хэши файлов будут скорее всего другими поэтому оно будет их компилить и ускорения не будет. Кроме тех случаев, когда версия пакета обновилась а программы нет, т.е всякие -p и -r релизы, в которых скорее всего идут косметические правки ебилдов. Т.е держать ccache нужно, ибо таких обновлений много, а вам я так понимаю вовсе не для работы нужны эти обноления, а для душевного успокоения что вы имете полностью обновленную систему. Если вам уж так нужно работать, то зачем вам постоянно обновляться?

Вот теперь я недопонял...

bes.internal написал(а):
Откомпилированые файлы брались из кэша, по md5 хэшу прекомпиленого файла - поэтому при пересборке оно ускоряется

То есть вы, без зазрения совести, хотите сказать, что если я сделаю расшаренный кеш для нескольких (идентичных
машин с одннаковыми флагами), то он заработает? ;)

Gentoo - Symphony of Creations

Если передача файла по каналу

Если передача файла по каналу связывающего ваши машины будет быстрее, чем его компиляция, а также будут совпадать chost ,cflags, use флаги то вроде как да

Интересно ...

Спасибо за информацию для размышлений, испытаю на досуге.
(Хотя отчасти и сомневаюсь что оно должно работать, слишком много параметров должны быть соблюдены)

Gentoo - Symphony of Creations

тут лучше сделать binhost или

тут лучше сделать binhost или distcc

Это я понимаю и реализовал

Просто для информации подковываюсь...

distcc не всегда устраивает, потому что не все задачи компиляции - распределяемы.
над binhost подумаю, так ли необходимо (ветки не совпадают).

кстати не по теме, но раз тут люди грамотные на этот счет:
почему distcc работает нормально, но в определенный момент пишет
что-то типа - распределение невозможно, компилирую локально,
хотя на не распределяемых задачах такое не выдает (например дрова от NV)
Ткните носом где смотреть. Спасибо.

Gentoo - Symphony of Creations

Обновление системы без ccache

Обновление системы без ccache никак работе не мешает, оно идет само по себе, я работаю сам по себе. Постоянно я не обновляюсь, периодически, по мере поступления сообщений о найденных критических уязвимостях.
Если эти -r и -р релизы имеют незначительное время компиляции, то ccache мне не нужен.
Поделитесь, как у вас xulrunner за 16 минут без ccache собрался, у меня вроде и компьютер не такой слабый: 3,1GHz, 1 GB.

aes78 написал(а): Поделитесь,

aes78 написал(а):
Поделитесь, как у вас xulrunner за 16 минут без ccache собрался, у меня вроде и компьютер не такой слабый: 3,1GHz, 1 GB.

Машинка все-таки посильнее немного - Intel Q6600 8Gb RAM, дисковая подсистема честная, на Adaptec 5405 с дисками в 10000 rpm - хотя в данном случае кроме процессора ничего остальное так не влияет на скорость сборки. Да, и сборка в 5 потоков одновременно, т.е. MAKEOPTS="-j5" - больше вроде никаких секретов...

если в новом ебилде что-то

если в новом ебилде что-то исправили, в итоге не затрагивающие ваши выходнык use флаги, то получается что вы просто будете компилировать тот же код что и раньше, поэтому кэш тут поможет, и это часто бывает. Также в кэш кладется работа autoconf (если я правильно понимаю строку autoconf compile/link ), а она идет в один поток, так что иногда занимает время большее чем сама компиляция.
В быстрой сборке нет никакой магии, просто новый ноут на i7 в 8 потоков

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".