Portage уже неторт!

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

Зачем соглашаться на медленное, если есть быстрое? Быстрого, конечно, пока еще нет, но..

Зачем соглашаться на медленное, если есть быстрое? Быстрого, конечно, пока еще нет, но..

А с такими подходами быстрого и не будет. Прежде чем бездумно бросаться на С или С++ нужно просто посмотреть а что же не так в текущем portage с python. А тут оказывается и увидеть время каждой операции в portage не проблема и конкретное место „тормоза“ вполне себе определяется и локализуется.

udept я прилепил к тому, что в процессе сборки зависимостей какого-нибудь пакета, сборка может закончится ошибкой. В таком случае уже не задумываешься о выполнении emerge для отдельного пакета с опцией --oneshot, чтобы он не помещался в world, в итоге данный файл разрастается, что в свою очередь тоже приводит к увеличению времени выполнения «emerge -auDNv system world». И данный скрипт несомненно полезен в данном случае и приведение его в соответствие новым возможностям portage, имхо, даст неплохой опыт в понимании как portage вычисляет зависимости, так как скрипт вроде как делает то же самое для записей из файла world.

P.S. это, как мне кажется, было бы полезно желающим переписать portage

Прежде чем бездумно бросаться на С или С++ нужно просто посмотреть а что же не так в текущем portage с python.

Не, тут ты, безусловно, прав, я лишь критикую подход «2мин vs 1мин — четакова?» :3

это, как мне кажется, было бы полезно желающим переписать portage

Они думают не о пользе. :)

И данный скрипт несомненно полезен в данном случае и приведение его в соответствие новым возможностям portage, имхо, даст неплохой опыт в понимании как portage вычисляет зависимости, так как скрипт вроде как делает то же самое для записей из файла world.

Главная проблема побороть те более 3к строчек на bash. :) И многое там конечно очевидно. Но есть и вообще темный лес.

В 10 раз конечно не ускорит, если просто портировать код на нормальный язык, без переделывания алгоритмов. Процентов на 20-30 шустрее бегать будет - уже хорошо.

Не, тут ты, безусловно, прав, я лишь критикую подход «2мин vs 1мин — четакова?» :3

Говоришь „А“ говори и „Б“. Уложится в одну минуту, или даже меньше, на gentoo? Да не проблема! Отматывай portage до времен eapi 2, 3 ставь только python2 и у тебя будет все офигенно и реактивно… Только одно маленькое и противное «Но» все фичи свежих eapi 4, 5 уйдут лесом. Но мы же говорим не про фичи а про время верно?

И да повторюсь я считаю что eapi 5 мне дает гораздо больше чем я имел на eapi 2 и эти две минуты расплата за то, какими фичами взамен потраченной лишней минуты времени я могу пользоваться на свежем portage!

В 10 раз конечно не ускорит, если просто портировать код на нормальный язык, без переделывания алгоритмов. Процентов на 20-30 шустрее бегать будет - уже хорошо.

Зачем что-то вообще переписывать на „нормальном языке“?

Конкретно как найти текущее узкое место вполне ясно. Дальше открывай, смотри и переделывай так чтоб не тормозило. И да как вариант это вынести тормозящий кусок из python в либу на сях. Собственно как зачастую и делают в подобных случаях.

Узкое место - python.
А если переписать на сях, узким местом будет /var/db/pkg

И в палудисе видимо тоже

Узкое место - python.

?

А если переписать на сях, узким местом будет /var/db/pkg

io там вообще не при чем. Осиль взять и проверить.

?

Python ест проц в 100% - это не узкое место?

Python ест проц в 100% - это не узкое место?

Это говорит лишь о том, что код portage никто даже не думал оптимизировать.

Откуда вы беретесь такие, расскажи? Ты понимаешь разницу между пакетником генты и аптом? Сразу признайся только, что не понимаешь, иначе бы такой ерунды не постил.

gcc с '-march=native -O3' наоптимизирует.

gcc с '-march=native -O3' наоптимизирует.

gcc наоптимизирует код на python? Да ты упорот!!!

Ты понимаешь разницу между пакетником генты и аптом?

А зачем ему её понимать? Ведь конкретно тут все именно только ради того чтобы ворваться и выдать „ЛОЛ!!!ОДИНОДИН портеж в гентах на петонах тормозит гыгы“. А то, что apt и portage просто не поддаются в сравнении, поскольку у них вообще разные задачи, его не интересует.

Нет, наоптимизирует код, переписанный на си с ненужного петона.

Нет, наоптимизирует код, переписанный на си с ненужного петона.

А в твоей вселенной он уже переписан? Ну ок сделай доброе дело сырцы в нашу вселенную на гитхаб залей.

По сравнению с дебианом тормозит (да да, я в курсе про юзы и слоты)

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

Started: 2013-10-28 15:44:11

Finished: 2013-10-29 15:46:01

и это даже не конпеляция

и это даже не конпеляция

Ага в торможении во время компиляции тоже виноват portage? Вот оно чо!

И да у тебя:

Started: 2013-10-28 15:44:11

Finished: 2013-10-29 15:46:01

Один день? Ты точно ничего не попутал?

А так все та же самая 00:01:50 и если я прав то и „тормозит“ у тебя там же

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

А сколько займет, когда kde новый свалится с обновлением 100500 пакетов? А если конфликт какой выявит, то чини\перезапускай. Вот так на обновление в итоге можно до часа убить. Да, это тормоза. Не тормоза это арч с его несколькими секундами. Вот бы так в генте.(Да, да, влажные мечты)

Да, это тормоза. Не тормоза это арч с его несколькими секундами. Вот бы так в генте.

Ну так бери и делай а не ной.

Кстати ты тут много повторяешь что новый EAPI и т.д. тормозов добавляет. был бы интересен вариант отключать фичи портаджа из командной строки ради скорости. Хочешь с фичами запускаешь --with-eapi5, хочешь скорости --with-eapi2. Имхо чтобы тупо проверить world на наличие обновлений модные и навороченные фичи нафиг не нужны.

У меня сейчас скребётся дикая идея, но проверить не скоро смогу. Сам по себе «emerge --rsync» или «eix-sync» тоже не быстр, ну да ладно. Идея вот какая: что если после обновления дерева в «emerge -auDNv» вместо «system world» подсунуть соответствующим образом урезанный выхлоп «eix-diff»? Насколько это будет быстрее и будут ли данные способы эквивалентны? Вроде как для отдельно обновляемых пакетов зависимости быстрее вычисляются, по сравнению с тем, если их перечень брать из world.

Имхо чтобы тупо проверить world на наличие обновлений модные и навороченные фичи нафиг не нужны.

eix-diff для подобной проверки не пойдёт?

Кстати ты тут много повторяешь что новый EAPI и т.д. тормозов добавляет. был бы интересен вариант отключать фичи портаджа из командной строки ради скорости. Хочешь с фичами запускаешь --with-eapi5, хочешь скорости --with-eapi2. Имхо чтобы тупо проверить world на наличие обновлений модные и навороченные фичи нафиг не нужны.

Нельзя отключить ненужные тебе версии eapi в portage поскольку переключатель находится в руках у системных профилей и конкретных ebuild-ов. А portage в каждом конкретном случае фактически просто смотрит на то какой именно eapi желает система и конкретный ebuild и именно им и пользуется.

А сама подержка eapi в portage реализована так, что на одной системе одновременно могут работают да хоть сразу версии eapi!

Разговор был о том, что portage версии = сегодняшняя - лет пять назад вместе с тем деревом и теми профилями на python2 вполне возможно и закономерно будет даже шустрее чем portage сегодняшней версии и сегодняшние профили и основное дерево.

Идея вот какая: что если после обновления дерева в «emerge -auDNv» вместо «system world» подсунуть соответствующим образом урезанный выхлоп «eix-diff»?

Если этот «eix-diff» или любой другой велосипед вместо него сможет выдавать только список обновленных ebuild-ов ну ок ты сэкономишь миллисекунды. А после того как ты скормишь полученный список только тех ebuild-ов которые можно обновить в portage он по твоему считать ничего не будет а вот прям так сразу начнет ставить то что ты ему приказал?

Самый реальный способ добиться ускорения это копать сырцы вон в том месте и переделывать все так чтобы вместо минуты на эту операцию тратились секунды.

Неее, я не к тому, что он ничего считать не будет, но считать зависимости вроде как должен для меньшего (иногда для намного меньшего) числа пакетов. Если обновляться не раз в полгода и не прилетает обновление какого-нибудь kde, то список пакетов для обновления обычно не такой большой и для него зависимости рассчитываться должны побыстрее чем для всего списка пакетов из файла world. Правда скорее всего, в лучшем случае, получится секунд 30 вместо 2 минут. Только нужно отсекать вариант, когда eix-diff будет пустым.

По поводу копания сырцов и идею где копать я понял. Но тут ничего сделать не смогу, да и сам portage я форкать не предлагал. Даже если и не форкать, то согласен, что оптимизация текущего кода в указанном месте не помешала бы.

У меня второй системой гента, дятел. Все я понимаю и ясно вижу, что Gentoo сливает.

У меня второй системой гента, дятел.

Это не прибавило тебе ума.

Все я понимаю и ясно вижу, что Gentoo сливает.

facepalm.
Ты либо толстый, либо тугой. И я не совсем понял, что именно.

Это не прибавило тебе ума.

А оно и не должно. Но в твоем сообщении ясно видно, что вы, гентушники, действительно считаете себя умнее остальных... Только за счет генты. Печально.

facepalm.

Сделай лучше facewall.

А оно и не должно. Но в твоем сообщении ясно видно, что вы, гентушники, действительно считаете себя умнее остальных... Только за счет генты. Печально.

А гента тут не причем. Просто для того, чтобы делать выводы о той или иной вещи - надо понимать, как она работает. Ты - не понимаешь.

хотя бы понимать её возможности, как работает это уже след уровень.

хотя бы понимать её возможности, как работает это уже след уровень.

Да, тоже бы хватило.

У меня второй системой гента

вы, гентушники, действительно считаете себя умнее остальных...

Доказал, чо :3

Еще нет. Гентушные разработчики изначально не тот язык выбрали, вот пусть переписывают теперь.

Тебе заскриншотить емердж?

Еще нет. Гентушные разработчики изначально не тот язык выбрали, вот пусть переписывают теперь.

А гентушные разработчики конкретно тебе или любому у кого «тормозит» что-то должны? Это gentoo - хочешь чтобы тебе было хорошо? Ну так бери и делай.

Я разве говорил что-то про емердж?

У них и у самих тормозит, только они этого не понимают.

Даже такой костыледром, как sorcery, написанный на баше, и тот быстрее.

Даже такой костыледром, как sorcery, написанный на баше, и тот быстрее.

Ага сказал так сказал. Этот твой костыледром не гуглиццо. И вообще угадай почему мне насрать на него.