From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.devel Subject: Re: Avoiding loading cc-langs Date: Sun, 07 Sep 2014 21:51:04 -0400 Message-ID: References: <20140831212355.GA4401@acm.acm> <20140906101233.GA3330@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1410141110 31560 80.91.229.3 (8 Sep 2014 01:51:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Sep 2014 01:51:50 +0000 (UTC) Cc: Alan Mackenzie , Martin Stjernholm , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: cc-mode-help-bounces@lists.sourceforge.net Mon Sep 08 03:51:43 2014 Return-path: Envelope-to: sf-cc-mode-help@m.gmane.org Original-Received: from lists.sourceforge.net ([216.34.181.88]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XQo7I-0003Hv-6F for sf-cc-mode-help@m.gmane.org; Mon, 08 Sep 2014 03:51:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=sfs-ml-2.v29.ch3.sourceforge.com) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XQo76-00025Y-2X; Mon, 08 Sep 2014 01:51:28 +0000 Original-Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XQo74-00025R-5O for cc-mode-help@lists.sourceforge.net; Mon, 08 Sep 2014 01:51:26 +0000 Received-SPF: softfail (sog-mx-4.v43.ch3.sourceforge.com: transitioning domain of iro.umontreal.ca does not designate 208.118.235.10 as permitted sender) client-ip=208.118.235.10; envelope-from=monnier@iro.umontreal.ca; helo=fencepost.gnu.org; Original-Received: from fencepost.gnu.org ([208.118.235.10]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1XQo73-00063A-3J for cc-mode-help@lists.sourceforge.net; Mon, 08 Sep 2014 01:51:26 +0000 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40612) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1XQo6x-0001Mv-4O for bug-cc-mode@gnu.org; Sun, 07 Sep 2014 21:51:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XQo6p-00036w-FS for bug-cc-mode@gnu.org; Sun, 07 Sep 2014 21:51:18 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_LOW autolearn=disabled version=3.3.2 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:6249) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQo6p-000354-C7; Sun, 07 Sep 2014 21:51:11 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNFpZEG/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kiAQI0hkXjnoHhDgEk0GVWIFqg0wh X-IPAS-Result: ArUGAIDvNVNFpZEG/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kiAQI0hkXjnoHhDgEk0GVWIFqg0wh X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="89045259" Original-Received: from 69-165-145-6.dsl.teksavvy.com (HELO ceviche.home) ([69.165.145.6]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2014 21:51:04 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 82E47660C4; Sun, 7 Sep 2014 21:51:04 -0400 (EDT) In-Reply-To: <20140906101233.GA3330@acm.acm> (Alan Mackenzie's message of "Sat, 6 Sep 2014 10:12:33 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) X-Headers-End: 1XQo73-00063A-3J X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Bug reports, feature requests, and general talk about CC Mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: cc-mode-help-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.emacs.cc-mode.general:6438 gmane.emacs.devel:174073 Archived-At: >> 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 ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk