Re: Avoiding loading cc-langs

[Stefan Monnier]

>> 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 think it more likely that when Martin created the c-lang-defvar
> mechanism, he partitioned the code such that what was not needed at
> run-time was placed in the separate file cc-langs.el, so as not to
> burden the run-time store occupancy needlessly.

Actually, a lot of what's in cc-langs.el *is* needed at run-time, but
it's copied into cc-mode.elc (and maybe cc-fonts.elc) so that
cc-langs.elc is not needed.
What proportion exactly, I don't know, admittedly.

>> 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.
> I think all these functions are cooperating to achieve one thing.  I'm
> not sure what you mean here by "the same thing".

They each have several alternative implementations: one for interpreted
case, one for the compiled case, one for the "compiled but the
version is changed so we can't use the pre-computed stuff", maybe yet
another one for when we're used within a c-lang-defconst, etc...

The way things like c-lang-const-expansion and c-langs-are-parametric
affect the semantics of other macros is still very unclear to me.

It's not at all obvious that the resulting semantics is always exactly
the same in all 3 cases (e.g. in c-major-mode-is, one of the 3 cases
(the one that falls back on c-lang-major-mode-is) seems to pay attention
to major-mode inheritance, whereas the other two cases don't seem to
handle it).

>> Is it only for performance reasons?
> I don't think so.  As I said, I think it [the not loading of cc-langs at
> run time] is to reduce store occupancy.

Ah, right, that would also be something to look at.  I'll take a look at
that aspect, thanks.

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

No, actually it's completely unrelated to Daniel's code (which I haven't
really looked at yet).  And my code is also untested so far with derived
modes (I did do a web search for derived modes, tho, and saw that there
are quite a number of them).  It's not even really tested at all so far.

> You're proposing a change whereby CC Mode would only be partially
> compiled at build time,

Actually, my recently installed changes to c-lang-defconst compiles
a bit more of the code at build-time (and I have similar changes for
c-lang-defvar).

So the effect is more that we don't *precompute* as many values.
And also, some of those precomputed values are functions, which we
currently manually byte-compile, whereas my patch leaves
them interpreted.  So in that part, we indeed compile less.

> and at each mode initialisation, a bit more would be compiled, but
> not everything.

No, compiling at mode initialization is too costly, so I just punt on it.

> The modes would be a bit slower to start, and a bit slower at
> run-time.

So far, the runtime is not affected.  But yes, the startup time is
slightly increased currently.

> They would occupy more store at run-time.

I haven't looked at it, so it might indeed be the case.  This said,
cc-mode.elc shrinks by 120KB and cc-fonts.elc shrinks by 100KB, so just
the fact of loading the 90KB of cc-langs.elc is not enough to make the
new situation worse.  Of course the dynamic generation of the mode
values is likely to require more memory.  As said, I haven't looked at
it yet, but it's indeed an important point.

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

The code as it stands is a liability (seen from the point of view of
the maintainer, whose main task I think is to make sure the code can be
maintained in the long run).

If we can get rid of those optimizations without any significant impact on
(cpu&memory) performance, then I think we should.


        Stefan