Comments 42
UFO just landed and posted this here
Ок, обновлю график.
Серьезно взялся за техническое писательство :)
ось Y должна быть всё же с нуля внизу начинатся, а не с 92. Иначе это просто обманка — данные отличаются на проценты, а стобцы — в разы.
Если уж на то пошло, то и тестировать нужно не одну программу, а несколько разноплановых приложений.
Да, график лжет, такая подача материала для рекламы хороша=)
Но если иллюстрировать им не фразу «prelink офигенно уменьшает время работы», а «выигрыш от использования preload значительно меньше, чем от использования prelink» то этот график пойдёт.
Хотя и тест очень сферический, запуск php -v чуть более чем полностью состоит из загрузки php в память, в то время как нормальные программы выполняют после своего запуска хоть какую-то работу (в идеале время потраченное на запуск намного меньше времени работы)
Но если иллюстрировать им не фразу «prelink офигенно уменьшает время работы», а «выигрыш от использования preload значительно меньше, чем от использования prelink» то этот график пойдёт.
Хотя и тест очень сферический, запуск php -v чуть более чем полностью состоит из загрузки php в память, в то время как нормальные программы выполняют после своего запуска хоть какую-то работу (в идеале время потраченное на запуск намного меньше времени работы)
UFO just landed and posted this here
preload в opensuse 11.3 с desktop-ядром устанавливается сам
а почему нет отдельно preload на графике?
Глянул на график — в 2 раза ускорение, супер! Присмотрелся, всего-то ~ 9%… Не наглядно как-то.
У меня eclipse будет быстрее 2 часов загружаться?
Есть мнение что Prelink больше не нужен
www.google.ru/#q=Prelink++DT_GNU_HASH&hl=ru
www.google.ru/#q=Prelink++DT_GNU_HASH&hl=ru
буквально, вчера наткнулся на статью habrahabr.ru/blogs/linux/20901/
там более подробно расписано о preload.
проверил — действительно стало немного шустрей работать.
там более подробно расписано о preload.
проверил — действительно стало немного шустрей работать.
это для вебсерверов может быть полезным или только для desktop'ов?
точнее что можно prelink'овать и preload'ить на вебсервере?
точнее что можно prelink'овать и preload'ить на вебсервере?
То что часто запускается.
/ КО
/ КО
ну тогда к вебсерверам это не применимо, т.к. там все запускается только один раз и постоянно висит в памяти
По preload я тоже пока не понял, есть ли в нём смысл при не перезагружающейся машине.
При не перезагружающейся — есть. Вы ведь браузер, текстовые радакторы, терминалы, плееры и т.д. постоянно запускаете. На сервере — смысла нет, т.к. там всё запускается всего один раз и без всяких preload'ов из памяти не выгрузится.
"-f — Вынуждает повторить предварительное связывание для файлов, которые уже подвергались ему. Это необходимо, т.к. программа prelink прекращает обработку существующих старых связанных файлов, зависимые библиотеки которых могли измениться."
-f --force
Force re-prelinking even for already prelinked objects whose dependencies are unchanged.
-f --force
Force re-prelinking even for already prelinked objects whose dependencies are unchanged.
Взглянул на график и с первого взгляда показалось, что увеличивает скорость более, чем в 2 раза. Но потом посмотрел на шкалу в миллисекундах и понял, что не в 2, а скорее в 1,1 раза. Совсем несущественно.
ммм… что-то мне это напоминает… кажется, тоже на «pre» начинается
Насколько использование prelink безопасно? Есть шансы, что всё поломается при следующем обновлении?
Спасибо, preload уже давно пользуюсь!
UFO just landed and posted this here
Тестирование в статье — чистая и наглая спекуляция.
Утверждаю это, как человек, посвятивший год жизни проблеме времени стартапа приложений (решение этой проблемы в некотором частном случае было темой моего диплома) и сломавший немало копий только на тестировании времени старта.
В комментариях выше уже говорилось про график, начинающийся не от нуля, а также малое количество протестированных приложений.
Но хотелось бы прояснить еще пару моментов.
Во-первых, разницу в менее чем 10 мс нельзя считать заслугой каких-либо оптимизаций, потому что любой фоновый процесс в системе может изменить время старта на сотню-другую милисекунд, не говоря уже о десятках.
Во-вторых, существуют термины «холодного» и «горячего» старта, то есть когда приложение незакешировано в памяти (до первого запуска) и закешировано, соответсвенно. Разница между холодным и горячем стартом приложения может измеряться секундами, а то и десятками секунд в зависимости от размеров приложения. Соответственно, если автор не гарантировал холодный старт, то тест, вообще говоря, абсолютно ничего не показывает.
Кроме того, немного искажена информация о Preload.
Он не просто бездумно кеширует часто-используемые файлы и библиотеки.
Он изучает последовательности загружаемых приложений и библиотек, чтобы в следующий раз, когда вы запускаете программу А, он догадался сразу загрузить библиотеки В и С, которые обычно грузятся сразу после А.
Поэтому, более показательным был бы пример с полной загрузкой системы (я, например, после использования Preload заметил явное визуальное ускорение в загрузке KDE).
Утверждаю это, как человек, посвятивший год жизни проблеме времени стартапа приложений (решение этой проблемы в некотором частном случае было темой моего диплома) и сломавший немало копий только на тестировании времени старта.
В комментариях выше уже говорилось про график, начинающийся не от нуля, а также малое количество протестированных приложений.
Но хотелось бы прояснить еще пару моментов.
Во-первых, разницу в менее чем 10 мс нельзя считать заслугой каких-либо оптимизаций, потому что любой фоновый процесс в системе может изменить время старта на сотню-другую милисекунд, не говоря уже о десятках.
Во-вторых, существуют термины «холодного» и «горячего» старта, то есть когда приложение незакешировано в памяти (до первого запуска) и закешировано, соответсвенно. Разница между холодным и горячем стартом приложения может измеряться секундами, а то и десятками секунд в зависимости от размеров приложения. Соответственно, если автор не гарантировал холодный старт, то тест, вообще говоря, абсолютно ничего не показывает.
Кроме того, немного искажена информация о Preload.
Он не просто бездумно кеширует часто-используемые файлы и библиотеки.
Он изучает последовательности загружаемых приложений и библиотек, чтобы в следующий раз, когда вы запускаете программу А, он догадался сразу загрузить библиотеки В и С, которые обычно грузятся сразу после А.
Поэтому, более показательным был бы пример с полной загрузкой системы (я, например, после использования Preload заметил явное визуальное ускорение в загрузке KDE).
нюню… спецы по сусе (от новелла) на форумах пишут, что смысла особого в прелоаде нет. в чём на собственной практике убедился изучив чего он там кеширует и тд… к примеру в сусе, имо, не очень внятные настройки. они кагбе не «самозатачивающиеся» отнюдь. самому менять это можно конечно, я даже сделал…
но особо выйгрыша не получил и забил. не так часто ребутится комп.
но особо выйгрыша не получил и забил. не так часто ребутится комп.
>>Можно назначить его на запуск по cron.
А как его добавить в расписание cron?
Он разве не только со скриптами работает?
А как его добавить в расписание cron?
Он разве не только со скриптами работает?
Sign up to leave a comment.
Prelink и Preload для ускорения запуска программ в Linux