Значительное улучшение первого старта программ в snap.
Меня, как снапкрафтера, очень интересует всё связанное с форматом snap. Технология самодостаточных пакетов с обязательной работой в профилях мандатного доступа имеет много как хейтеров, так и поклонников, которые понимают что такое работа в ежовых рукавицах AppArmor или SELinux и какие плюсы это даёт. Естественно, пока технология только начинает своё развитие - есть на пути становления и детские болезни и шероховатости, но в целом snap базируется на правильных вещах и движется правильным курсом. Одним из неприятных до сего моментом был долгий первый старт программы, связанный с тем, что многое ещё не было подготовлено, но данный факт очень плохо влиял на отношение рядовых пользователей к программам в snap. Как говорят профи, это ухудшает User eXperience (UX). Разработчики всерьёз взялись за решение ситуации и разительно снизили время первого старта программы от 2 до 6 раз!
Взгляд на проблему
Подробно об устройстве snap вам лучше прочесть в статье Snap vs Deb, а тут кратко попытаюсь объяснить суть долгого первого старта программы в snap пакете.
Мир Deb - это дискретное управление доступом. Программа стартует и получает доступ ко всему что дают классические права доступа (chmod + chown), сохраняемые в атрибутах файлов и каталогов. Поэтому когда во время установки любого софта из control скриптов ({pre|post}{inst|rm} ) вызываются с правами root различные утилиты, такие как обновление кэша шрифтов (fc-cache), обновление общей базы MIME (update-mime-database), обновление кэша иконок (update-icon-caches) и т.д, то результатами работы данных утилит могут в дальнейшем пользоваться ВСЕ программы в мире deb, благодаря правам доступа на чтение. Другими словами и кратко: ставите одну программу, установщик софта распакует программу и вызовет из под рута нужные утилиты, а результатами длительной работы пользуются все программы.
Давайте рассмотрим теперь что не так со snap. Этот формат задумывался как самодостаточный, то есть максимально не зависящий от системы, и безопасный, благодаря системе мандатного доступа. Безопасность и удобство всегда были в противоположных углах ринга. Софт в snap изолирован друг от друга и от системы (пакет ubuntu-core), к которой он имеет ограниченный и фильтрированный доступ. Поэтому всё что можно делать софту deb в дискретном мире, нельзя делать софту snap в мандатном мире. Программа snap хоть и изолирована, но она не находится в сферичном вакууме, просто при первом старте программы, ещё много "не налажено мостиков" с системой, что выливается в первичный долгий старт.
Чтобы оценить масштаб трагедии, разработчики в качестве подопытного кролика взяли Visual Studio Code, который в мире deb под управлением Ubuntu 18.10 на ПК с 6 ядрами Xeon(TM), 64 Гб ОЗУ и диском 2 Тб 970 EVO NVMe SSD стартует в свой первый раз за 15 секунд против 119 секунд в snap.
Разработчики провели множество тестов с замерами старта программ RPM/DEB/SNAP на различном оборудовании и результаты ещё раз убедительно доказали что мощь аппаратуры абсолютно не причём.
Я уже и без разработчиков самостоятельно выяснил при упаковке своих подопечных, что львиную долю первого старта съедает fc-cache, которые создаёт "собственический" кэш в домашней папке для данной конкретной программы.
Ситуация со шрифтами и доступом к системным темам оформления (themes) с самого начала была странная. Непонятно почему разработчики опасались шрифтов, не содержащих программного кода, и его кэша и не реализовали доступ к ним из темницы мандатного доступа?
С темами действительно сейчас нужно быть осторожными. Теперь они не просто набор картинок, но JS + CSS. Но шрифты-то? Непонятно!
Улучшение в создании кэша Fontconfig
Как бы то ни было, разрабы сделали улучшения и с версии 2.36.2 нас ждёт готовый кэш шрифтов, который будет обновляться на этапе установки программы в snap формате. Прямая аналогия с миром deb.
Теперь на всё той же вышеописанной мощной машине Visual Studio Code стартует в первый раз в мире deb за 15 секунд и 22 секунды в snap.
На этом разработчики не останавливаются и продолжают находить возможность оптимизации и уменьшения первого старта программы. К примеру, в тестах найдена задержка в 2-3 секунды при холодном старте, связанная с различными факторами. Например, Visual Studio Code при старте должен подгрузить свои ~80 библиотек, что приводит к ~9700 операциям I/O против ~4500 I/O в мире deb, так как изоляция snap идёт в разрез с философией shared library. Тем не менее, можно смягчить и этот "удар", но об этом разработчики напишут в следующих статьях.
Итоги
Разработчикам можно открыто поставить в вину что они упустили ситуацию с внешним видом программ snap и первичным долгим стартом программ. Они были заняты "подкапотными работами", забыв что встречают по одёжке.
Понять мощь snap на десктопе, где смогли уладить безопасность с удобством могут не многие люди, а вот увидеть визуальные огрехи и лишний раз ткнуть пальцем в рану - таких много. Но лучше поздно чем никогда и такие шаги по оптимизации и ускорению - можно только приветствовать. Так как snap не завязан жёстко на Ubuntu и работает в различных дистрибутивах, то затронуты в положительном смысле будут многие и это радует.
Статья была написана под влиянием Snap startup time improvements
