Re: Avoiding loading cc-langs

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> In my attempt to understand a bit more how cc-mode works, here's the
> next question:
> - why do we work so hard to try and make cc-langs unnecessary at run-time?
> I mean, if you look at c-lang-const, or c-make-init-lang-vars-fun,
> you'll see we have up to 3 different ways to do the same thing in
> different circumstances.
> Is it only for performance reasons?

Digging further into this: I have now a patch which gets rid of this
"pre-compute cc-langs stuff and hardcode it into cc-mode.elc and
cc-fonts.elc", by computing those things dynamically at
run-time instead.

The naive way to do that leads to a problem, tho: some of the computed
elements are functions which are then byte-compiled, so if we do that
dynamically, we end up calling the byte-compiler at run-time, which
increases the startup time significantly (almost double for an empty
c-mode file).

Luckily, it turns out that those functions we dynamically byte-compile
don't run noticeably slower when not byte-compiled (99% of their
run-time is spent in other functions, e.g. the regexp-matcher).

So if we refrain from byte-compiling them, the result is a simpler setup
that starts just a bit slower (on my test machine, enabling c-mode for
the first time, in an empty buffer takes 0.56s instead of 0.47s).

One of the main benefits I see of those two changes (setting things up
more dynamically and not calling the byte-compiler explicitly) is that
it should make most of the cc-bytecomp horror completely useless (some
of its main purpose is to propagate a compiling environment from one
place to another, e.g. to the compiler called explicitly).  I haven't
yet investigated this part, tho, admittedly.

It should also make cc-mode's build dependencies sufficiently normal
that we don't need any special Makefile.in rules for cc-mode any more.


        Stefan