Portage уже неторт!

Поехали дальше…

emerge --update --newuse --deep @world @system -epv

These are the packages that would be merged, in reverse order:

2013-10-28 15:55:18: Calculating dependencies \
2013-10-28 15:55:27: Adding root packages /
2013-10-28 15:55:35: Processing dependencies /
2013-10-28 15:56:32: Checking for slot conflicts  
2013-10-28 15:56:32: Trying to accept blocker conflicts   
2013-10-28 15:56:32: Resolving slot conflicts for complete graph  -
2013-10-28 15:56:32: Processing slot conflicts   
2013-10-28 15:56:32: Triggering slot operator reinstalls   
2013-10-28 15:56:32: Validating blockers  |
2013-10-28 15:56:40: Checking for blocker conflicts  
2013-10-28 15:56:40: Checking for rebuild triggers  
2013-10-28 15:56:40: Checking if restart is needed  
2013-10-28 15:56:40: Checking if we have to prune rebuilds  
2013-10-28 15:56:40: Checking if restart is needed  
2013-10-28 15:56:40: Checking for parameters that change behavior  
2013-10-28 15:56:40: Checking for changes that are needed  
2013-10-28 15:56:40: Done resolving!... done!

И да если кому интересно то это все на

> eselect python show 
python3.3
> equery u portage
[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for sys-apps/portage-2.2.7:
 U I
 - - build                    : !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first half of
                                bootstrapping [make stage1]
 - - doc                      : Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally
 - - epydoc                   : Build html API documentation with epydoc.
 - + ipc                      : Use inter-process communication between portage and running ebuilds.
 + + linguas_ru               : Russian locale
 - - pypy2_0                  : Use pypy-c2.0 as Python interpreter.
 - - python2                  : Use python2 as Python interpreter.
 + + python3                  : Use python3 as Python interpreter.
 - - python_targets_python2_6 : Build with Python 2.6
 + + python_targets_python2_7 : Build with Python 2.7
 - - python_targets_python3_2 : Build with Python 3.2
 + + python_targets_python3_3 : Build with Python 3.3

Спасибо за патч O_o

Сколько у тебя пакетов на обновление на этот момент? Что нарезолвилось?

Мне кажется, или по полторы минуты считать всё-таки долго?

Portage тормозит? Где?

эээ 15:44:11 - 15:46:01

Итого:

• 00:01:50 секунд на emerge --update --newuse --deep @world @system -pv
• 00:01:22 на emerge --update --newuse --deep @world @system -epv

И я конечно возможно что-то таки и не понимаю. Однако хотелось бы спросить уважаемых господ где же здесь те самые мифические тормоза.

Ах и да если что:

Packages installed:   1047
Packages in world:    223
Packages in system:   62
Required packages:    1044

 * Mounting 2500M of memory to /var/tmp/portage ...                     [ ok ]
 * emerging -av --update --newuse --deep @world @system -pv
 * 
 * The FEATURES=digest setting can prevent corruption from being noticed.
 * The `repoman manifest` command is the preferred way to generate
 * manifests and it is capable of doing an entire repository or category at
 * once.
 * 

These are the packages that would be merged, in order:

2013-10-28 16:12:22: Calculating dependencies |
2013-10-28 16:12:24: Adding root packages \
2013-10-28 16:12:27: Processing dependencies \
2013-10-28 16:12:46: Checking for slot conflicts  
2013-10-28 16:12:46: Trying to accept blocker conflicts   
2013-10-28 16:12:46: Resolving slot conflicts for complete graph   
2013-10-28 16:12:46: Processing slot conflicts   
2013-10-28 16:12:46: Triggering slot operator reinstalls   
2013-10-28 16:12:52: Validating blockers  -
2013-10-28 16:12:53: Checking for blocker conflicts  
2013-10-28 16:12:53: Checking for rebuild triggers  
2013-10-28 16:12:53: Checking if restart is needed  
2013-10-28 16:12:53: Checking if we have to prune rebuilds  
2013-10-28 16:12:53: Checking if restart is needed  
2013-10-28 16:12:53: Checking for parameters that change behavior  
2013-10-28 16:12:53: Checking for changes that are needed  
2013-10-28 16:12:53: Done resolving!... done!

Total: 0 packages, Size of downloads: 0 kB
 * unmounting tmpfs ... 

840 пакетов = 31 секунда

я подозреваю что больше минуты это и есть тормоза

я подозреваю что больше минуты это и есть тормоза

И ладно ок. Второй раз по горячему и поэтому быстрее. А чтоб гарантированно получить нормальный результат снимать показания нужно иначе… Да знаю. Не дурак.

Но простите какие-то 2 сраных минуты на систему с более 1к ebuild-ов это тормоза?

все потому что мы забыли что такое производительность. я считаю что это ультра медленно. резолв зависимостей ведеться на питоне. людям некогда было переписывать это на сях я понимаю. но пришло время =)

Хм. Три раза повторило Processing dependencies. Видимо, в цикл какой ушло из-за криворукости. Итого чуть больше двух минут.

Ладно смотрим дальше… Вон еще результаты есть и уже можно делать общие выводы.

Самые большие и существенные задержки между Processing dependencies и Checking for slot conflicts у меня это оба раза по 00:00:57 и у sema1011 (для полноты отпишись какой версии python в системе и с какими USE собраны portage ) - 00:00:19 а остальное пролетает можно сказать что вообще незаметно.

ЗЫ а прикинь что творится на mips роутере, arm девайсе. компиляцию ты можешь легко отправить на мощный комп, но emerge, конфигурация и линковка будет выполняться на клиенте

Ну вот и куда ты залез со своим лицом в калашный ряд?

И да спасибо, продолжайте эта информация очень ценна для нас всех.

python3.3

А на pypу, кстати, ваш портаж работает?

Хотите и дальше разводить срачь? Успехов.

Хотите реально что-то сделать? Открыли TomWij / emerg.resolv.time_print.patch а там вы прекрасно увидите где конкретно в файле pym/_emerge/depgraph.py находятся Processing dependencies и Checking for slot conflicts а главное что ж там такое между ними происходит… Это вам конкретно место где можно приложить ваши силы чтоб „portage не тормозил“

Ну ты понял…

ЗЫ а прикинь что творится на mips роутере, arm девайсе. компиляцию ты можешь легко отправить на мощный комп, но emerge, конфигурация и линковка будет выполняться на клиенте

с какого перепугу? На билд-хосте всё будет запускаться

buildpkg чтоли? я имел ввиду просто distcc

Да, я в курсе, что urpmi безобразно долго, по сравнению с apt, синкает не изменившиеся источники, но если источники менялись, то результаты становятся близкими, при этом за 1:50 из стартопоста они успеют скачать и поставить с полсоточки пакетов помимо обновления инфы из реп.

А на pypу, кстати, ваш портаж работает?

Вообще работает. А конкретно мой нет поскольку я всем этим pypy вообще не заморачивался. Поскольку меня огорчает его время сборки, у моего ноута всего 3Гб озу а главное информация о pypy тоже весьма противоречивая. Кто-то пишет что на pypy все быстрее кто-то наоборот даже медленее. Но я думаю что если б там действительно все было так волшебно, то аппстрим gentoo уже давно б предпринял шаги в сторону pypy… А так… Не знаю меня это pypy как то не цепляет.

при этом за 1:50 из стартопоста они успеют скачать и поставить с полсоточки пакетов помимо обновления инфы из реп

Не сравнивай теплое с мягким. В этих ваших urpmi, apt нет и половины того что умеет portage а как известно расплата за фичи это время.

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

А собирать его жестоко, да.

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

Попробовать нужно. К тому же в gentoo есть и pypy-bin. Но как то просто руки не доходят… Да и смысл ну будет к примеру 1 минута вместо 2х на мой взгляд это не играет решающей роли.

а прикинь что творится на mips роутере, arm девайсе. компиляцию ты можешь легко отправить на мощный комп, но emerge, конфигурация и линковка будет выполняться на клиенте

А что на нем должно творится? На мой взгляд если учесть что в системе больше 1к ebuild-ов, довольно свежий portage, eapi 4 или 5 c @set-ами и прочими плюшками… Да я понимаю что для многих все это просто пустой звук. А по моему вполне нормально учитывая все те фичи которые мы имеем и используем.

Но простите какие-то 2 сраных минуты на систему с более 1к ebuild-ов это тормоза?

Да.

Да.

А ну ок… Так тебя это действительно волнует и тебе все еще непонятно что делать? Или это так очередное трололо?

И да на мой взгляд те 2 минуты на более 1к ebuild-ов вполне оправданы фичами которые мы получаем.

А вот если бы у тебя была гента ты бы взял и пересборал пор… э-э-э, погоди-ка :3

Да, я всё это понимаю, и считаю что оптимизировать Portage необходимо, но с учетом того, сколько времени занимается пере-сборка мира, это некритично. С использованием slite выполнение emerge -pvuDN world занимает всего 7 минут. Это на нетбуке. На десктопе примерно минута.

sqlite *

А вот если бы у тебя была гента ты бы взял и пересборал пор… э-э-э, погоди-ка :3

Mystra_x64 ага и вместо 2х минут я б видел результаты emerge --update --newuse --deep @world @system -pv за одну минуту! И эта одна минута безусловно играет колоссальное значение.

Меня это не волнует. Я просто высказал свое мнение.

С использованием sqlite выполнение emerge -pvuDN world занимает всего 7 минут.

Вот использование sqlite в portage это так же противоречиво как и pypy… У всех оно по разному и единого мнения нет.

Меня это не волнует. Я просто высказал свое мнение.

Так тогда ты попутал и тебе на самом деле вон туда.

Как только станет в 2 раза больше ебилдов ты сразу всё поймёшь :}

Как только станет в 2 раза больше ебилдов ты сразу всё поймёшь :}

Я вангую что в данном случае играет роль вовсе не количество ebuild-ов а во первых используемая версия python а во вторых eapi :)

Не берусь предсказывать как именно оно зависит от версии python но скорее всего на 2м будет иначе чем на 3м…

А вот eapi влияет непосредственно а главное чем выше версия (т.е. чем больше фич) тем медленее будет portage.

Поддерживаю. Именно это и говорил в соседней ветке где собрались paludis переписывать. Вместо почесания NIH помогите проекту если так хорошо C++ и алгоритмы знаете.

Checking for slot conflicts

Буковку 'h' в слове «slot» потеряли. :(

но emerge, конфигурация и линковка будет выполняться на клиенте

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

2 минуты пожирания проца в 100% тормознутым питоном - это и есть тормоза.
А вот было бы оно на сях...

Чего уж там, сразу на ассемблере. Лучше бы усилия сначала бросили на развитие udept (или форка, чтобы не ломать текущий проект), чтобы довести его до совместимости с новой версией portage, заодно потренировались бы в вычислении зависимостей

На промежутке от 44:11 до 46:01.

sergey@localhost:~/ > time apt-get dist-upgrade
Чтение списков пакетов… Готово
Построение дерева зависимостей       
Чтение информации о состоянии… Готово
Расчёт обновлений…Готово
обновлено 0, установлено 0 новых пакетов, для удаления отмечено 0 пакетов, и 0 пакетов не обновлено.
sudo apt-get dist-upgrade  1,01s user 0,07s system 80% cpu 1,350 total

Зачем на ассемблере? Разве gcc еще не лучше человека код оптимизирует?

Поддерживаю. Именно это и говорил в соседней ветке где собрались paludis переписывать. Вместо почесания NIH помогите проекту если так хорошо C++ и алгоритмы знаете.

А там вообще непонятно что именно они хотят делать. Но самое печальное что уже два топика там тупо не о чем.

Реально хотите как-то исправлять текущую ситуацию? Так берите и делайте.

2 минуты пожирания проца в 100% тормознутым питоном - это и есть тормоза.

А вот было бы оно на сях...

Бери палудис. Мужики говорят, что он на с++.

И опять же я вангую, что на eapi 2, 3 с python2 (т.е. на gentoo которая еще без понятия о @set-ах и прочих модных штуках) все будет гораздо шустрее.

Чего уж там, сразу на ассемблере. Лучше бы усилия сначала бросили на развитие udept (или форка, чтобы не ломать текущий проект), чтобы довести его до совместимости с новой версией portage, заодно потренировались бы в вычислении зависимостей

udept ты приплел вообще непонятно к чему. Если что то udept это вот что и нужно оно было для вполне конкретных целей. Просто печально что оно rip-нулось.

А с „тормозами portage“ хотели бы разобраться давно бы разобрались. Они ж не этого хотят.

Это я к тому, что маловероятно, что простое переписывание кода с python на C++ ускорит работу в 10 раз и сократит хотя бы до 6-10 секунд.
По поводу тормозов, то portage должен не только дерево пакетов разобрать, но ещё и обработать перед этим информацию из /var/db/pkg

P.S. у меня недавно была странный глюк, когда при всего лишь 2 gb директории distfiles скрипт eclean-dist выполнялся целый час О_о
Вот это я понимаю, тормоза, а вычисление зависимостей 1.5-2 минуты не так страшно.