Улучшения скорости snap с новым алгоритмом сжатия.
Многие знают что я с теплотой отношусь к строгим системам мандатного доступа (MAC) и когда они пришли в линукс мир, принял их. Многие пользователи и админы не понимают зачем им нужна строгость SELinux или AppArmor, но мне безопасность никогда не бывает лишней. Когда появились snap пакеты с обязательным профилем AppArmor, мне стало интересно как Canonical усадит на один стул вопрос удобства работы со snap вместе с безопасностью, настолько они в разных углах ринга. Snap хорошеют с каждым днём и это радует. Предлагаю вашему вниманию перевод статьи "Snap speed improvements with new compression algorithm!" от Игоря Любунчича (Igor Ljubuncic).
Безопасность и производительность часто являются взаимоисключающими понятиями. Отличный пользовательский интерфейс позволяет сочетать эти два аспекта таким образом, что, с одной стороны, не ставить под угрозу надёжные и прочные основы безопасности, а, с другой стороны, не мешать быстрому и отзывчивому взаимодействию с программой.
Snap представляют из себя самодостаточный (self-contained) пакет программы с многоуровневой безопасностью, в результате чего, иногда, может снижаться визуально воспринимаемая производительность по сравнению с тем же приложением, установленным традиционно. Разработчики, естественно, в курсе и прикладывали значительные усилия для устранения любых вопросов, связанных с производительностью, не забывая и не жертвуя безопасностью.
В прошлом году было реализовано значительное улучшение скорости запуска, за счёт оптимизации кеша fontconfig, который отъедал львиную долю во времени запуска программы в самый первый раз.
Теперь хочется поделиться новым улучшением - использование нового алгоритма сжатия, что позволит сократить время старта программы в 2-3 раза.
Алгоритмы LZO и XZ
По умолчанию, snap пакеты используют сжатую (только-на-чтение) файловую систему squashfs, с применением алгоритма XZ. Это позволяет получить высокую степень сжатия, но, как часто бывает, требует большой вычислительной мощности при распаковке. На десктопе, пользователь воспринимает такой старт программы как "медлительность". Это особенно заметно при первом старте программы. Последующие старты программы, как правило, быстрые и почти не отличаются от традиционно установленных аналогов.
Чтобы сократить время старта, разработчики решили протестировать другой алгоритм LZO, который предлагает чуть меньшее сжатие, но требует меньшей вычислительной мощности.
Для теста взяли браузер Chromium (stable build, 85.X). Пример показателен по нескольким причинам. Во-первых, браузер - это популярное и востребованное приложение, которое часто используется и любая потенциальная медлительность будет замечена. Во-вторых, Chromium - относительно большое и сложное приложение. В-третьих, он не является частью какой-либо конкретной среды рабочего стола Linux, что делает тестирование независимым и точным.
Для сравнения: snap с сжатием XZ весит ~150 МБ, а с сжатием LZO ~250 МБ.
Тестовый стенд и методология
Разработчики решили протестировать на ряде систем (модели ноутбуков 2015-2020 гг). Включая HDD, SSD и NVMe, графику Intel и Nvidia, а так же несколько операционных систем Kubuntu 18.04, Ubuntu 20.04 LTS, Ubuntu 20.10 (на дату написания оригинала статьи она ещё не вышла в релиз) и Fedora 32 Workstation. Считаем, что получился хороший микс из аппаратного и программного обеспечения, позволяющее лучше понять проделанную работу.
- Система 1. 4 ядра (8 потоков) Intel i5, 16 Гб ОЗУ, 500 Гб SSD, графика Intel UHD 620, Kubuntu 18.04.
- Система 2. 4 ядра Intel i3, 4 Гб ОЗУ, 1 Тб HDD 5400 rpm, графика Intel HD 440, 20.04 LTS.
- Система 3. 4 ядра Intel i3, 4 Гб ОЗУ, 1 Тб HDD 5400 rpm, графика Intel HD 440, Fedora 32 Workstation.
- Система 4. 4 ядра (8 потоков) Intel i7, 64 Гб ОЗУ, 1 TB NVMe, Nvidia GM204M (GeForce GTX 980M), Ubuntu 20.10.
| Платформа | Система 1 | Система 2 | Система 3 | Система 4 |
|---|---|---|---|---|
| Snapd версия | 2.46.1+18.04 | 2.47 | 2.45.3.1-1.fc32 | 2.47.1+20.10 |
| Ядро | 4.15.0-118-generic | 5.4.0-48-generic | 5.8.13-200.fc32 | 5.8.0-21-generic |
| Среда | Plasma | GNOME | GNOME | GNOME |
Каждую из систем проверяли на предмет затраченного времени старта и отображения окна браузера:
- Родной пакет (RPM или DEB) если он доступен (Kubuntu 18.04 and Fedora 32).
- Snap с XZ сжатием (все системы).
- Snap с LZO сжатием (все системы).
Сравнивали результаты:
- Холодный старт (ХС) - в памяти нет кешированных данных.
- Горячий старт (ГС) - данные браузера кешируются в памяти.
Результаты
Обратите внимание, что результаты очень показательны, но всегда есть место расхождению из-за общего состояния системы, текущей нагрузке от фоновых задач, использования диска, профиля вашего браузера, установленных плагинов и т.д.
| Chromium время старта | Родной пакет (DEB/RPM) ХС/ГС (сек) |
Snap с XZ ХС/ГС (сек) |
Snap с LZO ХС/ГС (сек) |
|---|---|---|---|
| Система 1 | 1.7/0.6 | 8.1/0.7 | 3.1/0.6 |
| Система 2 | N/A | 18.4/1.2 | 11.1/1.2 |
| Система 3 | 15.3/1.3 | 34.9/1.1 | 10.1/1.3 |
| Система 4 | N/A | 10.5/1.4 | 2.6/0.9 |
- Результаты были получены при многократных запусках. Взято среднее значение. Стандартное отклонение ~0.7 секунд при холодных стартах и ~0.1 секунд при горячих.
- Использование LZO улучшает холодный старт на 40-70%
- В Kubuntu 18.04 (Система 1), в которой Chromium по-прежнему доступен в виде пакета DEB, LZO теперь обеспечивает почти идентичную производительность при запуске!
- На Fedora 32 Workstation (Система 3) холодный запуск программы в LZO-сжатом snap быстрее, чем RPM-пакет, на довольно приличные 33% (фактическая разница в ~5 секунд)!
- Горячие запуски, в целом, не зависят от формата упаковки.
Для желающих протестить самому
Если вы захотите получить результаты старта браузера (или любого другого ПО) на вашем оборудовании, то подготовлен скрипт, который вы можете загрузить с GitHub.
Скрипт startup-time.sh позволяет сравнивать время запуска любого программного обеспечения (RPM/DEB) с snap и предназначен для работы с любым менеджером пакетов, поэтому вы можете использовать его в Ubuntu, Fedora, openSUSE, Manjaro и т.д.
Чтобы предотвратить любую потенциальную потерю данных, функции закомментированы в основном разделе скрипта, поэтому вам нужно будет вручную раскомментировать их, прежде чем скрипт что-либо сделает.
Итого
Разработчики довольны улучшениями, которое даёт LZO, поскольку разительно улучшает холодный старт программы. Но это не конец пути! Разработчики заняты целым рядом дополнительных улучшений и оптимизаций. Когда дело доходит до итогового размера snap пакета, можно значительно уменьшить его размер за счёт коннекта к другому snap (content), к примеру к snap с темами, шрифтами и т.д.
Скоро разработчики поделятся со второй итерацией исправления скорости создания кеша шрифтов.
В ближайшем будущем, снапкрафтерам будет доступна документация, в которой соберут лучшие решения для создания компактных, быстрых приложений в небольшом по размеру snap пакете.
Snap speed improvements with new compression algorithm!
by Igor Ljubuncic on 27 October 2020
От себя, как снапкрафтера, хочется добавить следующее. Обнаружил что вечно хорошеющий shell-скрипт desktop-launch (если его использует снапкрафтер) от разработчиков стал асинхронным и все функции запускаются параллельно, что хоть и немного ускоряет старт программы на многоядерных компьютерах.
В принципе, в данном месте можно сказать что основные болячки молодости snap устранены!
Через механизм content можно получить связь с системным snap пакетом, хранящим визуальные темы и шрифты. Это позволяет программе выглядеть красиво в той среде рабочего стола, что использует пользователь, и не тащить лишнего в снап пакет программы, что делает его постройнее в мегабайтах.
Скорость запуска, как вы поняли, на карандаше у разработчиков и они сделали (и сделают) многое для ускорения старта программы в snap.
Надеюсь не забыли, что в snap пакете программа в ежовых рукавицах системы мандатного профиля? Если вы это понимаете и осознаёте, что разработчики приносят безопасность на обычный десктоп, попутно решая массу проблем и увязывают столько далёкие друг от друга безопасность и удобство со скоростью.
Snap vs AppImage.
Snap vs Deb.
8 отличий snap от других систем доставки софта.
