WEBVTT

00:00.000 --> 00:11.620
Okay, so I'm going to tell to you about Frost IDL CPP and how you can make your

00:11.620 --> 00:16.660
rows to build faster and even if you're not using rows to be able to apply at least some

00:16.660 --> 00:19.420
of that to your own projects.

00:19.420 --> 00:25.860
So first before talking about Frost IDL CPP, we need to look at Frost IDL.

00:25.900 --> 00:31.160
So first of all, it's set of packages that is responsible for building your messages.

00:31.160 --> 00:38.640
So here we have an example for the pigs for messages package and this is the build process.

00:38.640 --> 00:44.780
Every color is a step in the build process and we can see that we have basically two types

00:44.780 --> 00:46.560
of steps.

00:46.560 --> 00:55.760
We have 10 long Python processes that are the Ross IDL Generators, they're taking quite

00:55.760 --> 01:02.160
a lot of time for this package because pigs for messages are over 100 interfaces.

01:02.160 --> 01:09.440
So it takes a lot of time to generate interfaces and there are smaller compilation steps

01:09.440 --> 01:11.000
that also need to be run.

01:11.000 --> 01:18.200
So you can use your messages in your projects.

01:18.200 --> 01:22.160
So for this package on my machine it took a minute 21 to build.

01:22.160 --> 01:27.680
So it's quite long, it's a large package but it's long just for interfaces.

01:27.680 --> 01:36.200
So my first IDL was to reimplement everything in C++ and by doing so, the Generators are

01:36.200 --> 01:39.440
between 30 to 300 times faster.

01:39.440 --> 01:44.720
So now the build is down to 13.8 seconds.

01:44.720 --> 01:46.320
So it's much faster.

01:46.320 --> 01:49.480
We can barely see the Generators anymore.

01:49.480 --> 01:54.960
As I in blue at the beginning, we have the generator for the Python interfaces at the end

01:54.960 --> 01:59.560
and in the middle size, like two or three of them.

01:59.560 --> 02:05.840
But it's much faster and now we see that it's actually the compilation steps as a Tarze

02:06.080 --> 02:11.080
and some of them are quite small at the beginning, the first ones are very small.

02:11.080 --> 02:18.160
But in the middle section, there are a few compilation steps that are over 100 milliseconds.

02:18.160 --> 02:21.800
So can we make this faster?

02:21.800 --> 02:25.520
Well, if we look in detail at what the compiler is doing.

02:25.520 --> 02:32.960
So GCC and Chrome they both have a time report that basically tells you what the compiler

02:33.000 --> 02:41.840
is spending time on and for those steps, the compiler is spending a lot of time parsing the files

02:41.840 --> 02:48.800
that he is trying to compile and even if your messages are small, it's still going to take

02:48.800 --> 02:55.960
a lot of time because all methods, they include headers and those headers, once the preposteriser

02:56.760 --> 03:06.840
can make files quite large and the compilation needs to parse files that are very large and

03:06.840 --> 03:14.600
moreover for every interface, the compiler is run multiple times and it's parsing the same files

03:14.600 --> 03:17.160
every time for every message.

03:17.160 --> 03:23.320
So when we have a situation like that, what we can use is pre-compiled headers.

03:23.320 --> 03:29.880
Pre-compiled headers, as well as are very easy to use with C-Max, there is a function target

03:29.880 --> 03:35.080
pre-compiled headers where you tell it which header you want to pre-compile and it will add

03:35.080 --> 03:42.280
a few steps that we see in green here that will pre-compile your headers and then that

03:42.280 --> 03:49.960
makes compilation steps much faster and with this we can get the compilation the build down to

03:49.960 --> 03:58.600
5.8 seconds for picks for messages but we can get even better, once I re-implemented the

03:58.600 --> 04:04.120
generators, I noticed that here we are seeing that they wait on each other, there are three

04:04.120 --> 04:09.320
of them that started the beginning, there are a few in the middle and pick Python is running

04:09.320 --> 04:15.640
last but in fact they don't depend on each other at all. So we can just run them right at the

04:15.720 --> 04:24.280
beginning and we will gain a few milliseconds in this case, this change was contributed back to

04:24.280 --> 04:30.440
RSIDL and on rolling it was merged two weeks ago, on rolling it shouldn't make the build

04:30.440 --> 04:40.200
almost twice as fast. So yeah that's it, check out RSIDL CPP, especially if you have very large

04:40.200 --> 04:42.600
packages with a lot of messages. Thank you.

04:45.640 --> 04:47.640
We're just going to have a little