Profiling native-compilation

[Eli Zaretskii <eliz@gnu.org>]

I tried to profile the code involved in native-compilation using
profiler.el, but the results seem to omit most of the functions
involved in that: the percents shown in the resulting profile are very
low, which seems to hint that most of the CPU time is spent in places
that profiler.el cannot identify.

Is it possible to use profiler.el to produce a meaningful profile of
native-compilation?  If yes, how does one go about setting up such
profiling?  And if this is not currently possible, why isn't it, and
can we do something to make the situation better?  For example, for at
least two C functions that are important to see in the profile -- GC
and redisplay -- we did arrange to be shown in the profile.  So if the
problem is that most of the time is spent inside C code, perhaps we
could do something similar in comp.c?

I think this is important because native-compilation is quite slow,
and at least I don't have a clear idea where most of that time is
spent.  Andrea, you said once that most of the time is spent in
libgccjit functions, which I find strange, since those are basically
parts of GCC code, and I don't think I ever saw such slow compilation
times from GCC.  So I guess there's more here than meets the eye, and
I think we should work on getting a clear idea where the time is
spent, so that we could improve it.  For example, if indeed libgccjit
is the main sink, we should ask the respective GCC developers to speed
it up.

Thanks.