Ubuntu snap采用新压缩算法lzo,app启动速度提高2-3倍

原创
2021/04/02 21:40
阅读数 183

Ref: https://ubuntu.com//blog/snap-speed-improvements-with-new-compression-algorithm 安全性和性能通常是互斥的概念。出色的用户体验是一种设法将二者融合在一起的方式,一方面不会在稳固而坚实的安全基础上妥协,另一方面却不会造成快速响应的软件交互。

snap是独立的应用程序,具有分层的安全性,因此,与通过传统Linux打包机制提供的相同应用程序相比,snap有时可能会降低感知性能。我们对这种现象非常了解,我们在解决安全隐患的同时也投入了大量的精力和时间来解决任何速度差距。去年,我们谈到了fontconfig缓存优化之后改进的snap启动时间。现在,我们想告诉您另一个重要的里程碑–为snap使用新的压缩算法可将应用程序启动时间缩短2-3倍!

LZO和XZ算法

默认情况下,使用XZ算法将snap打包为压缩的只读squashfs文件系统。这导致高级别的压缩,但是因此需要更多处理能力来解压缩和扩展文件系统以供使用。在台式机上,用户可能会将此视为“缓慢”,即应用程序启动所花费的时间。在仅将应用程序数据缓存在内存中之前,这仅在首次启动时更为明显。随后的启动速度很快,通常,与传统打包的应用程序相比,几乎没有差异。

为了缩短启动时间,我们决定测试另一种算法-LZO,该算法提供较少的压缩,但需要较少的处理能力来完成操作。选择LZO算法因为它在许多不同的用例中都提供了最高的兼容性。

作为测试用例,我们选择了Chromium浏览器(稳定的版本85.X)。我们认为,由于几个原因,这是一个非常有代表性的案例。第一,浏览器是一种无处不在(且很流行)的应用程序,使用频率很高,因此任何潜在的运行缓慢都可能会引起注意。第二,铬是一个相对较大且复杂的应用程序。第三,它不是任何特定的Linux桌面环境的一部分,这使得测试独立且准确。

为了进行比较,XZ压缩的snap重约150 MB,而使用LZO压缩的snap重约250 MB。

测试系统和方法

我们决定在一系列系统(2015-2020年笔记本电脑型号)上进行测试,包括HDD,SSD和NVMe存储,Intel和Nvidia图形以及包括Kubuntu 18.04,Ubuntu 20.04 LTS,Ubuntu 20.10(在撰写本文时预发布)和Fedora 32 Workstation(就在Fedora 33发布之前)。我们相信这可以很好地结合硬件和软件,使我们对我们的工作有更广泛的了解。

  • 系统1具有4核/ 8线程Intel(R)i5(TM)处理器,16GB RAM,500GB SSD和Intel(R)UHD 620图形,运行Kubuntu 18.04。
  • System 2具有4核Intel(R)i3(TM)处理器,4GB RAM,1TB 5,400rpm机械硬盘和Intel(R)HD 440图形,运行Ubuntu 20.04 LTS。
  • 系统3具有4个核Intel(R)13(TM)处理器,4GB RAM,1TB 5400转机械硬盘,和Intel(R)HD 440倍的图形,运行Fedora 32工作站。
  • System 4具有4核/ 8线程Intel®i7™处理器,64GB RAM,1TB NVMe硬盘和Nvidia GM204M(GeForce GTX 980M),运行Ubuntu 20.10。
平台 系统1 系统2 系统3 系统4
snap版本 2.46.1 + 18.04 2.47 2.45.3.1-1.fc32 2.47.1 + 20.10
核心 4.15.0-118通用 5.4.0-48通用 5.8.13-200.fc32 5.8.0-21通用
等离子体 GNOME GNOME GNOME

在每个选定的系统上,我们检查了启动和显示浏览器窗口所花费的时间:

  • 可用的本机软件包(DEB或RPM)(Kubuntu 18.04和Fedora 32)。
  • 使用XZ压缩进行snap(所有系统)。
  • 使用LZO压缩进行snap(所有系统)。

我们通过以下方式比较了结果:

  • 冷启动–内存中没有缓存的数据。
  • 热启动–浏览器数据缓存在内存中。

结果!

我们使用新的未使用的配置文件测量了Chromium浏览器的启动时间。请注意,这些结果具有很高的指示性,但交互式使用情况度量始终存在一定程度的差异,这可能是由于您的总体系统状态,由于其他后台活动,磁盘使用情况,浏览器配置文件导致的当前系统负载等导致的以及附加组件和其他因素。

铬启动时间 本机包(DEB / RPM) 冷/热(s) 通过XZ压缩捕捉 冷/热(s) 使用LZO压缩捕捉 冷/热(s)
系统1 1.7 / 0.6 8.1 / 0.7 3.1 / 0.6
系统2 不适用 18.4 / 1.2 11.1 / 1.2
系统3 15.3 / 1.3 34.9 / 1.1 10.1 / 1.3
系统4 不适用 10.5 / 1.4 2.6 / 0.9
  • 表中的结果是多次运行的平均值。对于冷启动,标准偏差为〜0.7秒,对于热启动,标准偏差为〜0.1秒。
  • 与XZ压缩相比,使用LZO压缩可将冷启动性能提高40-74%
  • 在Kubuntu 18.04系统上,它仍然具有Chromium作为DEB软件包,现在,LZO压缩的snap提供了几乎相同的启动性能!
  • 在Fedora 32工作站上,LZO压缩的快速冷启动比RPM软件包快了相当可观的33%(实际相差约5.0秒)。
  • 热启动在很大程度上与包装格式的选择无关。

如果您想自己测试一下...

您可能对分析浏览器或任何与此相关的应用程序的启动时间感兴趣。为此,我们编译了一个脚本,您可以下载该脚本(链接到GitHub Gist),使该文件可执行,然后在您的系统上运行。该脚本使您可以将所有本机软件包的启动时间与snap进行比较,并且可以与任何软件包管理器一起使用,因此您可以在Ubuntu,Fedora,openSUSE,Manjaro等上使用此脚本。

为防止任何潜在的数据丢失,该功能在脚本的主要部分中已被注释掉,因此您需要在脚本执行任何操作之前手动取消注释它们。

概括

我们对LZO压缩带来的改进感到满意,因为它使用户可以更快,更简化地使用snap。现在,我们可以研究引入和推出与其他snap相似的更改的最佳方法。

这绝不是旅程的终点!离得很远。我们正在努力进行一系列其他改进和优化。说到大小,可以使用内容捕捉和舞台捕捉来减少捕捉的一面,也可以使用snapcraft扩展。我们还在研究一组新的字体缓存修复程序,与此主题有关的故事也很引人注目,我们将很快分享。我们打算在不久的将来发布指南,以帮助开发人员减少snap并减小其整体大小,所有这些都可以帮助创建更精简,更快的应用程序。

如果您对此主题有任何意见或建议,我们希望听听他们的意见。您可以告诉我们您对snap启动性能的发现,并向我们指出您认为应该解决的任何明显问题或问题,包括您认为应该进行概要分析和优化的任何特定snap。我们一直在努力改善用户体验,并且会注意到您可能有的任何反馈。同时,享受您的快速浏览!

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部