[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Avoiding loading cc-langs
From: |
Stefan Monnier |
Subject: |
Re: Avoiding loading cc-langs |
Date: |
Sun, 07 Sep 2014 21:51:04 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) |
>> 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