Firefox из репозитория (Bon Echo) очень тормозит и лагает

Система “без паники”, обновлённая и настроенная (недавно перешёл на Arch со Slackware).
Довольно странная картина, какое-то время пользовался Firefox (Bon Echo) из репозитория (с яндекса) и он просто жутко тормозил. Постоянно, на больших и средних страницах появлялись какие-то лаги, а если вкладок открыто несколько - то вообще мрак. При том что на Слаквари всё работало просто отменно.
Короче, я взял и установил прямо с оффсайта мозиллы простым копированием в /usr/lib , и о чудо, тормоза куда-то исчезли, всё стало работать плавно и замечательно.
Отсюда вопрос, что там намудрили в репозитории, или этот глюк только у меня проявлялся?
Посмотреть правила сборки в твоем abs, возможно что как раз с параметрами что-то намудрено, сейчас использую Minefield (FF 3 beta2) самособранный из AUR есть тормоза на страницах с разметкой только на div+css, на beta1 такого не было.
systemd должен умереть.
Да нет, firefox не из abs, он вообще-то из extra, за номером 2.0.0.11-2 то есть я просто не ожидал такого подвоха…
Из abs  у меня только пара пакетов (не успел ещё обжиться по настоящему :-) но к сабжу они не относятся.
Firefox из репозитория о себе говорил, что он называется Bon Echo 2.0.0.11 и по ощущениям, он просто раз в 10 медленнее чем “родной” с оффсайта (2.0.0.12). Даже на страничках с простым текстом скроллинг шёл с рывками и лагами.
Не знаю уж, как он так был собран гениально, чтоб такое замедление получить…

На эту же тему, была ещё одна проблема с kpdf. Тоже, так тормозил, что просто мрак. При перелистывании, страницы отображались с задержкой в пару секунд, а то и больше. Оказалось, всё дело в его дефолтном конфиге. Уж откуда он такой взялся (я его точно таким не делал), но там было всё выставлено в “false”, так что тоже в силу тормозов работать просто было невозможно, даже на маленьких документах. Как обычно решилось убиванием конфига и созданием дефолтного.

Просто непонятно, откуда такое берётся? Это ж надо просто специально так делать, “само” оно ведь так не происходит, и чувствую что ещё не раз придётся мне тут с этим столкнуться.

В остальном, конечно очень доволен системой Arch. Ещё ничего и никогда не было таким простым и послушным и лёгким в настройке, это очень радует :)
мда, ты знаешь что ABS является отображением того что потом в репозитариях в бинарном виде? т.е. глядя на правила сборки FF в abs можно узнать как он собирался. Ну и попробывать подправить под себя, поэксперементироввать, после подбора опитамального запостить баг-репорт. потом будет уже сборка  с новыми правилами.

ЗЫ процессор не АМД?
systemd должен умереть.
Процессор - Athlon64 X2. А это что-то меняет? По моему всё собирается -march=i686 -mtune=generic и вряд ли тут амд как-то может повлиять на процесс, более того, нигде особо так и не влияет.
А с firefox - тот который из репозитория был удалён, а на его место установил в бинарном виде с оффсайта, с прописыванием симлинков и перетаскиванием в нужное место плагинов. Теперь лагов нет и скорость отрисовки просто фантастическая.
А вот что именно непонятные тормоза на процах AMD при использовании i686 наблюдаются :( у меня AMD, но дистрибутив x86_64, там все порхает, на Duron 800 (i686), даже консоль чуть лагает. Просто попробуй исправить -mtune на своё и пересобрать FF через ABS, и покажи результаты.
systemd должен умереть.
Гм…. я вот тоже задумался об этом.
То что лагает неприятно и неуместно, я уже заметил. Сразу скажу - на Слаке такого в помине небыло, и вообще если бы там не был такой убогий подход к пакетам, то я бы наверное на слаке и остался, но…
Казалось бы всё настроил, всё (с оговорками) работает, и фаерфокс теперь летает, но…. сама система постоянно притормаживает, замирает, что-то постоянно подвисает.
Особенно вчера, уже ночью, начался просто кошмар какой-то. Было открыто несколько приложений, штук 10 примерно (памяти у меня достаточно - 2 Гб), и началось. Сначала намертво завис krusader, потом и остальные части KDE тоже начали безобразничать и тормозить. Через какое-то время (примерно через минуту) krusader “отвис”, но терпение моё уже на исходе.
Создаётся ощущение, что это что-то с ядром, особенно это мне показалось после вчерашнего намёка на AMD. В остальном, вроде бы параметры сборки для AMD вполне приемлимые.

В догонку ещё один вопрос о Arch AMD64. Как там дела обстоят с наполнением пакетами? Сильно хуже чем в x86?
Я когда-то экспериментировал с 64 битными дистрами, Bluewhite64 и т.д. и у меня сложилось впечатление что головной боли слишком много, а преимуществ слишком мало, если они вообще есть. В то время как недостатков хоть отбавляй. Память там поедается - просто ужас. Почти в два раза больше надо на то же самое. А прибавки скорости для десктопа почти нет, да и проблемы с 32бит библиотеками присутствуют. Поэтому я это дело забросил.
Если пакеты не 32bit онли то в этой части Arch и Arch64 одинаковы. По поводу лагов, попробывать сменить планировщик IO (кстати, покажи какой у тебя сейчасcat /sys/block/hda/queue/scheduler) и сменить планировщик CPU (тут вроде только пересборка), пока самому времени проверять нет
systemd должен умереть.
Хех, IO планировщик я уже неделю назад поменял на “elevator=as”  ;) но это не очень помогает, по моему.
И в /etc/hosts у меня всё правильно вписано, это я всё уже проходил.
Просто такое ощущение, что в системе что-то “не так”. Она по отклику, что для десктопа очень важно, просто ОЧЕНЬ медленная.
Есть ещё проблема с libata, т.е. встроенный баг с UDMA для pata дисков. Выше udma2 не включается, т.к. ей кажется (что неверно) что у меня подключен 40-выводный кабель. Эта проблема уже в баг-листах, но у меня вообще есть сильное желание откатиться на ide, чтоб было как у Патрика - hda, sda и т.д. , вроде бы (по офф конфе) это возможно, надо только грамотно, для моего чипсета поправить /etc/mkinitcpio.conf, ну и соответственно править /etc/fstab и /etc/lilo.conf (или что-то там для grub, я им не пользуюсь, не знаю)
Но только от этого лаuи не должны быть, особенно такие сильные. Это просто фризы уже, а не лаги, если бывает по нескольку секунд приложение замирает. Вряд ли тут в планировщике дело.
Что я могу ответить, на втором АМД - картина полностью дублирует твою, причем после летнего апдейта (2007 года). Что делать? сравнить версии компилятора чем собирается система и сравнить параметры сборки с эталоном, в твоём случае со шлакварью. Сделать выводы подтвержденные замерами и запостить развернутый баг-репорт.
systemd должен умереть.
 
Зарегистрироваться или войдите чтобы оставить сообщение.