Welcome to Part 5 of our “Optimise your ROS snap” blog series. Make sure to check Part 4. This fifth part is going to cover two different optimisations. The first one, covers the compression algorithm. The second one, is about implementing extremely risky but efficient file deletion.
<!–p>Part 6 of this series will present the conclusion of our optimisation as well as their results and real life use cases.
</p–
We are going to present two completely different optimisations in this article. The first one is a tradeoff that will totally depend on our final application use case. The second one is more of an experiment to see how far we can go in terms of minimising the size of a ROS snap.
Changing the compression algorithm
By using the kde-neon extension, our snap is enforced to use the compression method LZO. The details are explained in the blog post: why-lzo-was-chosen-as-the-new-compression-method.
What interests us here is that the XZ compression is normally the default,…
