Optimise your ROS snap – Part 2

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 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: 

• 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 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 and 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 that are readily available (especially for desktop). In our case, the 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. 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 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 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 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!

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 are also subject to this first tip.

If we don’t remember the metrics that we are using, we can review Part 1 of this blog series. Similarly, a 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 and might be the case in the future.

Continue reading Part 3 of this series.