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