Optimise your ROS snap – Part 6

Welcome to Part 6 of our “Optimise your ROS snap” blog series. Make sure to check Part 5. This sixth and final part will  summarise every optimisation that we did. We will provide a critique for every optimisation that we tried along this series of blogs.

Finally, we have reached the last part of this blog post series exploring how to optimise ROS snaps. Now it’s time to conclude on our results. This series of blogs was inspired by various other blogs posted on the ubuntu.com/blog website.

What we learned about ROS snap optimisation

Throughout these blog posts, we tried various ways to improve our snap in terms of time or space. While some optimisations only had benefits (Compiling in Release, removing unnecessary files, cleaning up content-sharing duplicates) some other optimisations would need particular care and awareness. Optimising a snap shouldn’t compromise its stability, after all, snaps are also made for resilience.

A snap that would receive very few updates and benefit from a lot of testing could leverage some of the most ambitious optimisations.

None of the optimisations that we applied here are specific to ROS, so we should feel free to experiment these on other snaps.

Also, we must keep in mind that snap packages bundle all their dependencies. This means we will never make them as small as a package technology that relies on other packages as dependencies (like Debian packages). Snaps are completely self-contained. They offer stability and a universal Linux packaging format but cannot have all the benefits of other package formats.

All the optimisations that we presented in this blog post series are available on the branch feat/optimization in the gazebo_snap repository. Since we did not apply all of them to the Gazebo snap, the ones actually used were merged in the gazebo_snap GitHub repository. If you have any feedback or ideas regarding the optimisation of ROS snaps or snaps in general, please join our forum and let us know what you think. Furthermore, have a look at the snap documentation if you want to learn more about snaps for robotics applications. The developer guide will come handy to learn how to deploy robotics applications with snaps.

You might also be interested in:

• How-are-we-improving-firefox-snap-performance-part-1, part2 and part3
• How-to-make-snaps-faster

What we learned about ROS snap optimisations is that there are various ways to optimise a snap. The optimisation from Part 2 should be widely used while the rest depends on each case. Because of how ROS Debian packages are defined and depend on each other, a ROS snap carries a lot of files and packages that are necessary for our applications. Hopefully this blog post series helped you understand what files are packed in a snap and the different ways to optimise their size.

Results summary

Here we will find a table of all the results. This way, we can quickly compare. As an example, with the optimisations we applied to the Gazebo snap available on the Snap Store we have reduced its size by more than 40%. Since snaps automatically update, we freed 333 MB on systems that had the previous version without optimisations.

Gazebo snap	Cold start	Hot start	RTF	.snap size	Installed snap size
Debug without content sharing	6.51	3.55	0.35	890 M	4.0 G
Debug	6.40	3.51	0.35	661 M	2.8 G
Release	6.06	2.72	4.39	232 M	758 M
Initial clean-up	6.02	2.73	4.67	211 M	674 M
Remove useless Debians	6.09	2.75	4.36	193 M	626 M
Cleanup content sharing duplicates	6.03	2.76	4.29	119 M	427 M
Ld-cache	6.07	2.74	3.96	119 M	427 M
XZ compression	6.97	3.71	4.03	86 M	427 M
Extreme trimming	5.67	2.74	4.14	39 M	115 M
Extreme trimming + XZ compression	6.96	3.75	4.14	29 M	115 M

Thank you for optimising the Gazebo snap with us, you can read the different parts of this blog post series following the different links:

Part 1 of this series will present the possible problems ROS snap might face, as well as the methodologies to measure it.

Part 2 of this series will present the optimisations already present in our Gazebo snap.

Part 3 of this series will present safe optimisations consisting of removing duplicates and unnecessary files.

Part 4 of this series will present the dynamic library caching optimisation.

Part 5 of this series will present alternative compressions as well as a risky but efficient optimisation.

If you have any feedback, questions or ideas regarding ROS snap optimisations, please join our forum and let us know what you think. Furthermore, have a look at the snap documentation if you want to learn more about snaps for robotics applications.