[devel] I: repocop test for %{get_version ...} is disabled.
Денис Смирнов
mithraen на freesource.info
Пт Авг 24 08:12:41 MSK 2012
On Fri, Aug 24, 2012 at 04:52:34AM +0400, Алексей Турбин wrote:
> Какой смысл критиковать апт за поиск по тексту? Ты знаешь как он
> работает? Никакого вспомогательного индекса для этого нету,
Только мне кажется что здесь первая и последняя фраза противоречат
друг-другу? :)
> он просто
> откупоривает скоченные pkglist.classic файлы и шестерит их. Логика -
> поиск всё равно выполняется пользователем, несколько секунд он подождет.
16 это не несколько, это дофига. И как раз такую простую операцию как
поиск я лично ожидаю в такой ситуации видеть за 1с максимум.
AT> Либо ядро глючит, либо слишком мало RAM на машине (меньше 2G).
$ free -m
total used free shared buffers cached
Mem: 3032 2829 203 0 122 1275
-/+ buffers/cache: 1430 1601
Swap: 3906 1165 2740
AT> Ядру ведь надо где-то взять 60 метров, чтобы этот файл в память загрузить,
AT> и еще несколько таких файлов есть.
О ужас, оно еще и пытается целиком эти 60 метров втянуть? Там реально
нужен random доступ?
AT> А если у тебя фаерфокс запущен, или,
AT> прости Господи, флеш плеер? Ядро оно что, должно тебе взять кредит в
AT> Банке реконструкции и развития?
Запущены chromium и emacs. Два самых страшных монстра. Они неплохо
соревнуются кто из них монструознее :-/
Но, кажется, мне придется часть наездов на apt забрать назад.
apt-get install bash (в системе где он установлен) выполняется более 10-и
секунд (это повторный запуск, когда большинство уже в кэше).
Виновник обнаружен: rpm-dir. Я ожидал, что при его использовании кэш
строится только при apt-get update, видимо это не так.
Комментирование строчки с репозиторием (локальные сборки пакетов) сразу же
ускоряет в 5 раз.
apt-cache search стал работать за 3 секунды, что хоть по моему мнению и
тормоза, но в приличных рамках.
--
С уважением, Денис
http://mithraen.ru/
----------------------------------------------------------------------------
Подробная информация о списке рассылки Devel