Pull to refresh

Comments 42

UFO just landed and posted this here
Серьезно взялся за техническое писательство :)
ось Y должна быть всё же с нуля внизу начинатся, а не с 92. Иначе это просто обманка — данные отличаются на проценты, а стобцы — в разы.
Если уж на то пошло, то и тестировать нужно не одну программу, а несколько разноплановых приложений.
Да, график лжет, такая подача материала для рекламы хороша=)

Но если иллюстрировать им не фразу «prelink офигенно уменьшает время работы», а «выигрыш от использования preload значительно меньше, чем от использования prelink» то этот график пойдёт.

Хотя и тест очень сферический, запуск php -v чуть более чем полностью состоит из загрузки php в память, в то время как нормальные программы выполняют после своего запуска хоть какую-то работу (в идеале время потраченное на запуск намного меньше времени работы)
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
preload в opensuse 11.3 с desktop-ядром устанавливается сам
а почему нет отдельно preload на графике?
Глянул на график — в 2 раза ускорение, супер! Присмотрелся, всего-то ~ 9%… Не наглядно как-то.
Да, на графике наглое надувательство!
У меня eclipse будет быстрее 2 часов загружаться?
врядли
только jvm стартанет быстрее в лучшем случае
Из графика создаётся впечатление, что прирост скорости будет более чем в 2 раза. На самом деле, он меньше 10%

Спасибо за корректировку, добавил ссылку на Ваш комментарий в пост.
Because these lookups have to be done whether or not the shared libraries involved have been prelinked, prelinking and DT_GNU_HASH are complementary and systems can do both.
Конкретную ссылку можете дать?
буквально, вчера наткнулся на статью habrahabr.ru/blogs/linux/20901/
там более подробно расписано о preload.
проверил — действительно стало немного шустрей работать.
это для вебсерверов может быть полезным или только для desktop'ов?

точнее что можно prelink'овать и preload'ить на вебсервере?
То что часто запускается.
/ КО
ну тогда к вебсерверам это не применимо, т.к. там все запускается только один раз и постоянно висит в памяти
По preload я тоже пока не понял, есть ли в нём смысл при не перезагружающейся машине.
При не перезагружающейся — есть. Вы ведь браузер, текстовые радакторы, терминалы, плееры и т.д. постоянно запускаете. На сервере — смысла нет, т.к. там всё запускается всего один раз и без всяких preload'ов из памяти не выгрузится.
Однако, например, на сервере мониторинга — актуально. Тот же Nagios постоянно запускает пинги и прочие тесты.

Но скрипты и приложения могут запускаться для каждого запроса?

"-f — Вынуждает повторить предварительное связывание для файлов, которые уже подвергались ему. Это необходимо, т.к. программа prelink прекращает обработку существующих старых связанных файлов, зависимые библиотеки которых могли измениться."

-f --force
Force re-prelinking even for already prelinked objects whose dependencies are unchanged.
Спасибо за исправление, добавил ссылку на Ваш комментарий в пост.
Взглянул на график и с первого взгляда показалось, что увеличивает скорость более, чем в 2 раза. Но потом посмотрел на шкалу в миллисекундах и понял, что не в 2, а скорее в 1,1 раза. Совсем несущественно.
во блин. не обновил страничку. Про график уже отписали. Не успел
ммм… что-то мне это напоминает… кажется, тоже на «pre» начинается
Насколько использование prelink безопасно? Есть шансы, что всё поломается при следующем обновлении?
Ничего не поломается, но после обновления prelink необходимо запустить снова.
UFO just landed and posted this here
Тестирование в статье — чистая и наглая спекуляция.

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

В комментариях выше уже говорилось про график, начинающийся не от нуля, а также малое количество протестированных приложений.
Но хотелось бы прояснить еще пару моментов.

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

Во-вторых, существуют термины «холодного» и «горячего» старта, то есть когда приложение незакешировано в памяти (до первого запуска) и закешировано, соответсвенно. Разница между холодным и горячем стартом приложения может измеряться секундами, а то и десятками секунд в зависимости от размеров приложения. Соответственно, если автор не гарантировал холодный старт, то тест, вообще говоря, абсолютно ничего не показывает.

Кроме того, немного искажена информация о Preload.
Он не просто бездумно кеширует часто-используемые файлы и библиотеки.
Он изучает последовательности загружаемых приложений и библиотек, чтобы в следующий раз, когда вы запускаете программу А, он догадался сразу загрузить библиотеки В и С, которые обычно грузятся сразу после А.

Поэтому, более показательным был бы пример с полной загрузкой системы (я, например, после использования Preload заметил явное визуальное ускорение в загрузке KDE).
нюню… спецы по сусе (от новелла) на форумах пишут, что смысла особого в прелоаде нет. в чём на собственной практике убедился изучив чего он там кеширует и тд… к примеру в сусе, имо, не очень внятные настройки. они кагбе не «самозатачивающиеся» отнюдь. самому менять это можно конечно, я даже сделал…
но особо выйгрыша не получил и забил. не так часто ребутится комп.

Это как форточный prefetch. Чем картофельные, тем заметнее.

>>Можно назначить его на запуск по cron.

А как его добавить в расписание cron?
Он разве не только со скриптами работает?
Sign up to leave a comment.

Articles