Portage тормоза уже неторт!

Как нетрудно заметить в 31 сек/8 сек=3,875 раза т.е. в 3,875 раза ускоряется процесс

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

от уменьшения объёма дерева portage от официального до минимально необходимого количества ebuild-ов в дереве и при прочих неизменных.

P.S.Ещё раз увижу от тебя такое неуважение к Ъ и я тебе сделаю что-то плохое. Фу таким быть.

У меня за то же время, что портаж рассчитывает зависимости, успевает скомпилироваться несколько пакетов.

А оценка где? Где, я тебя спрашиваю, красивые графики зависимости времени выполнения операций от количества пакетов? Как я узнаю экспоненциальный там рост или всего лишь порядка квадратного корня?

Тебе надо? Вот бери и строй.

То есть оценки нет и не будет? Так и не вводи людей в заблуждение.

То есть оценки нет и не будет?

То есть у тебя повылазило? Или ты читать/считать не умеешь?

А графики строить это уж ты дружочек сам.

То есть по твоему

Как нетрудно заметить в 31 сек/8 сек=3,875 раза

это оценка зависимости скорости от размера? Две точки это не оценка зависимости, а просто две точки.

Или ты читать/считать не умеешь?

И это говорит человек не уважающий Ъ? Стыдно должно быть.

Две точки это не оценка зависимости, а просто две точки.

А ты сделал хотя-бы эти две точки? Нет? Ну тогда давайпокадосвидания.

И это говорит человек не уважающий Ъ?

Gentoo-шники всех твоих Ъ дом труба шатали а потому-что не читать документацию есть зло.

Gentoo-шники всех твоих Ъ дом труба шатали а потому-что не читать документацию есть зло.

Повтори это как только гентушники во всех своих дефолтных профилях по умолчанию добавят use флаг -doc, чтобы читать документацию на внешних ресурсах, а не на localhost'е.

поставь paludis, если тебе скорость нужна, и выпили systemd, еретик!

Еще мой тред добавь про тормоза portage: Тормоза emerge:-(

Кстати некисло времени накидывает опция "--with-bdeps=y"

Еще мой тред добавь про тормоза portage

Сделано.

Кстати некисло времени накидывает опция "--with-bdeps=y"

А ещё есть забавные --ignore-built-slot-operator-deps=y и --rebuild-if-new-slot=n которые тоже нехило так влияют.

У портежа нет никакой БД, и он каждый раз бегает по всему дереву?

А ещё есть забавные

Что значит забавные? эта опция пересобирает ломающиеся пакеты при обновлении, насколько я помню.

Я прикручивал sqlite, шото не очень помогло.

Ну sqlite для хранения дерева и не подходит. Я тоже когда-то пробовал прикручивать. Тут нужна какая-то БД, которая с графами зависимостей работает и оптимизирует запросы вида «выдай мне все зависимости, исключая уже установленные».

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

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

На самом деле можно однажды сгенерить кэш зависимостей, а потом просто в него вносить diff при каждом emerge --sync, это все вполне реализуемо. Можно даже напедалить какую-нибудь свою внутреннюю БД со своим форматом, дабы не тянуть кучу зависимостей в stage3, просто этим никто не занимается. А я это не сделаю, т.к. не программер.

можно однажды сгенерить кэш зависимостей, а потом просто в него вносить diff при каждом emerge --sync, это все вполне реализуемо

Не только. Нужно ещё при каждом ручном измении ебилдов как-то отлавливать, что изменилось. Или перегенеривать весь кэш с нуля.

Как нетрудно заметить в 31 сек/8 сек=3,875 раза т.е. в 3,875 раза ускоряется процесс

ускоряется процесс разбора доступных пакетов.

То есть, грубо говоря, при установке пакета на голую систему ты выигрываешь восемь секунд, что обычно является статистически незначимой погрешностью. Вот не пофиг ли, установится geeqie за минуту или за минуту и восемь секунд? Не пофиг ли, накатятся апдейты из сотни пакетов за час или час и восемь секунд? (Ради политкорректности временем сборки софта в генте было решено пренебречь)

У портежа нет никакой БД, и он каждый раз бегает по всему дереву?

Там кеш с кучей мелких файлов.

И что в нём лежит?

То есть, точно говоря, и как уже успели заметить выше, я получил две точки зависимости. А дальше 3,875 это то во сколько раз быстрее portage посчитает объём пакетов из stage3 с дефолтными USE флагами на минимальном дереве потрежей (в котором исключительно только то что в самом stage3 и ничего более) относительно официальной свалки портежей и при прочих равных условиях.

http://forums.gentoo.org/viewtopic.php?t=261580

Кто-то пробовал?

А что, надо быстро? Честно? Ну подтормаживает, всё равно раз в неделю запускаешь. Не понимаю я этого плача. Макось быстрее обновляется. Перейдём?

Это

Там походу просто пострипаные ебилды. Добавить бы в них по полному дереву зависимостей, и будет норм.

сегодня эксперементировал с запихиванием всех кешев и портежей в озу при помощи tmpfs. Туда поместил /usr/portage, /var/db/pkg, /var/cache

от этого никакого радикального ускорения просчёта зависимостей не происходит, время ускоряется процентов на 30, а используется при этом примерно 1 ядро из 4.

Правда у меня paludis, но думаю что результат будет примерно такой же и для emerge

Тут нужна какая-то БД, которая с графами зависимостей работает и оптимизирует запросы вида «выдай мне все зависимости, исключая уже установленные».

А как реализован дебиановский кеш зависимостей? Наверняка есть какая-то хитрость.

Достаточно затолкать их в одну базу. Большая часть времени (по крайней мере, в паладисе) уходит на работу с фс и разбор таких файлов.

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

поставь paludis, если тебе скорость не нужна

пофикшено

У меня кеш лежит в базе sqlite, и у меня ssd, так что i/o как-то до лампочки - не помогло.

при каждом ручном измении ебилдов

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

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

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

Хитрость в том, что у дебиана зависимости проще. Никаких флагов, слотов, сабслотов и прочего.

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

А кто говорит про однозначность? В depends и так есть свой синтаксис с флагами и or/and, достаточно в кэш-файлах вписать туда не только прямые «соседние» зависимости, а все, в том же формате. Считать и парсить список будет так же долго, но хотя бы по многим файлам бегать не надо будет.

И вот тут он его посчитает быстро или очень быстро, или, даже, может, быть медленно. Допустим, он его будет считать целую минуту!

А потом он начнет собирать твой stage3. За сколько минут он его соберет? Не окажется ли время работы любого алгоритма подсчета в пределах статистической погрешности относительно времени выполнения остальных операций?

Тогда ССЗБ, и при указании этих опций не должен использоваться кеш.

Допустим, он его будет считать целую минуту!

А это и всё остальное Капитан я и без тебя прекрасно знаю.

Тогда ССЗБ, и при указании этих опций не должен использоваться кеш.

Как это не должен? Да при thin-manifests изменение ebuild-а никак не отобразится на контрольной сумме в манифесте потому-что в этом случае она там тупо вовсе не учитывается. Однако при всем при этом зависимости строить и в случае thin-manifests никто не мешает.

кеш лежит в базе sqlite

Это который search-index? Это не то, он только cave search ускоряет.

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

Без понятия что там лежит, делал так

А, я думал у тебя paludis.

нет, у меня portage, и его тормоза весьма печалят меня.

У меня кеш лежит в базе sqlite, и у меня ssd, так что i/o как-то до лампочки - не помогло.

На макбуке использую gentoo prefix. Дохлый i5, ssd и дефольтно-настроенный портаж - emerge работает шустро.

На лэптопе с дохлым i7 и базой в sqlite на sata 7200rpm тормоза жестокие.

Угу, а еще он считает контрольные суммы _всех_ ебилдов при любом обсчете зависимостей. Внезапно обнаружил это после того, как начал писать кастомный ебилд в /usr/local/portage и забросил, не сгенерировав Manifest после последней правки.

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

Ну да… или не считает но кому какое дело не правда ли?

Дохлый i5
Дохлый i7

Извините, а где вы такое дохлое железо берете? :)

Сравнение ssd и hdd вообще неуместно. Они совершенно разные, да и преимущество в плане скорости будет в любом случае за ssd.