Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting our team. We will be in touch shortly.Close

  1. Blog
  2. Article

gbeuzeboc
on 27 April 2023


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:

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 snapCold startHot startRTF.snap sizeInstalled snap size
Debug without content sharing6.513.550.35890 M4.0 G
Debug6.403.510.35661 M2.8 G
Release6.062.724.39232 M758 M
Initial clean-up6.022.734.67211 M674 M
Remove useless Debians6.092.754.36193 M626 M
Cleanup content sharing duplicates6.032.764.29119 M427 M
Ld-cache6.072.743.96119 M 427 M
XZ compression6.973.714.0386 M427 M
Extreme trimming5.672.744.1439 M115 M
Extreme trimming + XZ compression6.963.754.1429 M115 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.

Related posts


gbeuzeboc
21 April 2023

Optimise your ROS snap – Part 4

Robotics Article

Welcome to Part 4 of our “optimise your ROS snap” blog series. Make sure to check Part 3 before. This fourth part is going to explain what dynamic library caching is. We will present how to use it to optimise ROS snaps, along with the different points to be careful about. Finally, we will apply ...


gbeuzeboc
17 April 2023

Optimise your ROS snap – Part 3

Robotics Article

Welcome to Part 3 of our “optimise your ROS snap” blog series. Make sure to check Part 2. This third part is going to present safe optimisations consisting of removing duplicates and unnecessary files. We will present three different methods as well as their cumulative benefits for the performance of ROS snaps. When snaps are ...


gbeuzeboc
11 April 2023

Optimise your ROS snap – Part 2

Robotics Article

Welcome to Part 2 of the “optimise your ROS snap” blog series. Make sure to check Part 1 before reading this blog post. This second part is going to present initial optimisations already used in the Gazebo snap. We will present the benefit that they could bring to our ROS snaps as well as the ...