Re: Avoiding loading cc-langs

[Alan Mackenzie]

Hello, Stefan.

On Wed, Sep 03, 2014 at 10:38:09PM -0400, Stefan Monnier wrote:
> > 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.

Would that be Daniel Colascione's patch (or something derived from it)
which he proposed in May?  That proposal is still open.  As far as I
know, it hasn't yet been tested with derived modes (those using
c-add-language).

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

You're proposing a change whereby CC Mode would only be partially
compiled at build time, and at each mode initialisation, a bit more
would be compiled, but not everything.  The modes would be a bit slower
to start, and a bit slower at run-time.  They would occupy more store at
run-time.

I honestly can't see this as a good change.

If we were starting from that position and wondering whether or not to
put in the extra effort completely to compile CC Mode at build time, I
could understand somebody saying it wasn't worth the trouble.  But the
code for this complete compilation exists and is extraordinarily
reliable, even though complicated.  It cannot make sense to cut down its
functionality.

> 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

-- 
Alan Mackenzie (Nuremberg, Germany).