--- title: Optimise your ROS snap – Part 2 description: Optimise your ROS snap! This series of 6 blogs will show the tools and methodologies to measure and improve the performance of a snap. url: https://canonical.com/blog/optimise-your-ros-snap-part-2?format=md --- 1. [Blog](https://canonical.com/blog) 2. Article --- [gbeuzeboc](https://canonical.com/blog/author/gbeuzeboc "More about gbeuzeboc") 11 April 2023 # Optimise your ROS snap – Part 2 [robotics](https://canonical.com/blog/tag/robotics) [ROS](https://canonical.com/blog/tag/ros) [ROS 2](https://canonical.com/blog/tag/ros-2) [ROS2](https://canonical.com/blog/tag/ros2) [Snap](https://canonical.com/blog/tag/snap) [snapcraft](https://canonical.com/blog/tag/snapcraft) --- Share the article Welcome to Part 2 of the “optimise your ROS snap” blog series. Make sure to check [Part 1](https://ubuntu.com/blog/optimise-your-ros-snap-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 performance results. Before its release, the Gazebo snap was using two optimisations that we need to cover first. When calling `snapcraft`, every part defined in our `YAML` file is going through [different steps](https://snapcraft.io/docs/parts-lifecycle): * During the build step, parts will need all the build time dependencies. In the case of the Gazebo snap, we are mostly talking about ROS and Qt dependencies. In another case, it could be more. * At the stage step, our snap is going to pull all the necessary runtime dependencies in order to include them in our snap. This way, our snap application will have access to every library that it needs when running. This means that our snap must carry a lot of libraries (probably common to other snaps). Our snap is then heavier on the filesystem, to download, and will take more time during the first “cold start” of our snap. If snaps could share common libraries, it would limit the number of libraries needed to be included inside our snap, right? ## Content sharing, the kde-neon extension Before diving in, we must review the [content sharing feature](https://snapcraft.io/docs/content-interface) of snaps. One snap can share content, in our case libraries, with another one. In the case of Gazebo, the library Qt is a run-time dependency and however not included in our snap. Indeed, at run-time, our Gazebo snap is accessing various Qt libraries from another snap via content-sharing. Unsurprisingly, Gazebo is not the only snap using the Qt libraries. For instance, [plotjuggler](https://snapcraft.io/plotjuggler) and [qtcreator-ros](https://snapcraft.io/qtcreator-ros) are also using the Qt libraries for their GUIs. Hence, there is no need for all these snaps to carry the exact same libraries and configuration. They can be shared. ### Optimisation While we can create our own content-sharing snap, there are a [few extensions](https://snapcraft.io/docs/supported-extensions) that are readily available (especially for desktop). In our case, the [kde-neon-extension](https://snapcraft.io/docs/kde-neon-extension), developed by the KDE community, will take care of using the content sharing snap for Qt libraries, as well as initialising the environment properly for graphic applications. Hence, our final snap is not shipping its own Qt libraries and thus saving approximately 1.2Gb on the disk per application using the extension. If extensions like `kde-neon` can save us 1.2Gb of file size, we certainly need to review content sharing for our snaps. Whether it is by creating a new content-sharing snap or using an available extension, there are different methods we can apply content sharing to our ROS application. ## Release mode Gazebo being a `C++` application, it must be compiled. While the compilation of `C++` is not specific to ROS snaps, snap relies on tools (e.g. `make`, `cmake`, `colcon`, `catkin`) that can be configured to achieve various goals. In `C++`, we can build our application with various options. One of the most noticeable is the [debug option](https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html). This will produce debugging information, providing additional extra information for debugging. The downside is that our application will be dramatically slowed down. Additionally, various [optimisation options](https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html) can be enabled to attempt to improve the performance and/or code size at the expense of compilation time and possibly the ability to debug the program. With `colcon` and more generally with `CMake` on Linux, our `C++` code is built by default in debug build type. [Build types](https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html) are sets of predefined compiler options.  By default, `CMake` defines a number of standard configurations: `Debug`, `Release`, `RelWithDebInfo` and `MinSizeRel`, but custom build types can also be defined. Note that the snapcraft [`colcon` plugin](https://snapcraft.io/docs/the-colcon-plugin) is not modifying `colcon`/`CMake` default behaviour, which is therefore the `Debug` build type. ### Optimisation To enable the Release mode for our `colcon` plugin based part, we have to declare it in the `colcon-cmake-args` plugin-specific keywords list, “`-DCMAKE_BUILD_TYPE=Release`”. Similarly, we can disable building tests and documentation to speed up our build and make sure that no tests nor documentation from our `colcon` workspace end up in our snap. We do so by respectively specifying “`-DBUILD_TESTING=OFF`” and “`-DBUILD_DOCS=OFF`”. We can add the following modifications to our `snapcraft.yaml`: ``` gazebo: plugin: colcon source: . + colcon-cmake-args: + - "-DBUILD_TESTING=OFF" + - "-DBUILD_DOCS=OFF" + - "-DCMAKE_BUILD_TYPE=Release" ``` ## Results Now, the moment we’ve been waiting for… Here come the numbers! | | 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 with content sharing | 6.40 | 3.51 | 0.35 | 661 M | 2.8 G | | Release | 6.06 | 2.72 | 4.39 | 232 M | 758 M | In terms of size, the content-sharing optimisation has a great impact. We do not see any impact on runtime, so this only brings benefits. Finding libraries can be complex. But nothing that cannot be solved by defining environment variables. This optimisation has been kept for all the other optimisations and measurements. From these numbers, we clearly see that building our ROS parts in release clearly makes a difference not only in terms of time to launch, but also saves a lot of space. Most importantly, although that was somewhat expected, the performance of the application running has increased by a factor 13! Since distributing our snap in debug doesn’t have any benefit, we can state that one *must* always build its `C++` snap as `Release` build type. Note that the `catkin` and [CMake snapcraft plugins](https://snapcraft.io/docs/cmake-plugin) are also subject to this first tip. If we don’t remember the metrics that we are using, we can review [Part 1](https://ubuntu.com/blog/optimise-your-ros-snap-part-1) of this blog series. Similarly, a [developer guide](https://ubuntu.com/engage/Deploying-ros-applications-Developer-guide) is available in order to learn how to deploy ROS application with snaps. ## Conclusion Here we have seen the most common optimisations that could be applied to a `C++`/`Qt` snap. These optimisations are safe and already applied to the Gazebo snap. Especially, the “`Release` mode” should be applied to every single `C++` snap. While snapcraft tools are reproducing the default behaviour of tools like `cmake`/`colcon`/`catkin`, enabling optimisations by default is [under discussion](https://bugs.launchpad.net/snapcraft/+bug/1688703) and might be the case in the future. *Continue reading [Part 3](https://ubuntu.com/blog/optimise-your-ros-snap-part-3) of this series.* [Get in touch Interested in running Ubuntu in your organization?](https://ubuntu.com/about/contact-us/form) ## Sign up for our newsletter Get the latest Canonical news and updates in your inbox. Work email: \*I agree to receive information about Canonical's products and services. By submitting this form, I confirm that I have read and agree to [Canonical's Privacy Policy](https://canonical.com/legal/dataprivacy). Sign up ## Share on --- ## Related posts [### TurtleBot3 OpenCR firmware update from a snap](https://canonical.com/blog/turtlebot3-opencr-firmware-update-from-a-snap) The TurtleBot3 robot is a standard platform robot in the ROS community, and it’s a reference that Canonical knows well, since we’ve used it in our tutorials. As a matter of... [gbeuzeboc](https://canonical.com/blog/author/gbeuzeboc) 25 September 2024 [### Canonical is now a platinum member in the Open Source Robotics Alliance](https://canonical.com/blog/osra-membership) Ubuntu is the home of ROS. The very first ROS distribution, Box Turtle, launched on Ubuntu 8.04 LTS, Hardy Heron, and since then, Ubuntu and ROS have grown hand in hand. With... [Gabriel Aguiar Noury](https://canonical.com/blog/author/g-aguiar-noury) 20 August 2025 [### ROS Noetic is EOL – take action to maintain fleet security](https://canonical.com/blog/ros-noetic-is-eol-take-action-to-maintain-fleet-security) As of May 2025, the Robot Operating System (ROS) Noetic Ninjemys officially reached its end of life (EOL). First released in 2020 as the final ROS (1) distribution, ROS Noetic... [Florencia Cabral Berenfus](https://canonical.com/blog/author/flor-cabral) 8 August 2025 [### Extending ROS Noetic Support with ESM-Enabled Content Snaps](https://canonical.com/blog/extending-ros-noetic-support-with-esm-enabled-content-snaps) Canonical has now extended its ESM (Expanded Security Maintenance) for ROS coverage to ROS Noetic content-sharing snaps. With ESM for ROS now available in both deb and snap... [Florencia Cabral Berenfus](https://canonical.com/blog/author/flor-cabral) 17 December 2025