From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Avoiding loading cc-langs Date: Sat, 6 Sep 2014 11:10:26 +0000 Message-ID: <20140906111026.GB3330@acm.acm> References: <20140831212355.GA4401@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1410002182 26669 80.91.229.3 (6 Sep 2014 11:16:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Sep 2014 11:16:22 +0000 (UTC) Cc: Alan Mackenzie , Martin Stjernholm , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 06 13:16:15 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XQDyZ-0006Wd-Lk for ged-emacs-devel@m.gmane.org; Sat, 06 Sep 2014 13:16:15 +0200 Original-Received: from localhost ([::1]:34205 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQDyZ-0005Tw-7w for ged-emacs-devel@m.gmane.org; Sat, 06 Sep 2014 07:16:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQDyG-0005Su-KH for emacs-devel@gnu.org; Sat, 06 Sep 2014 07:16:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XQDy8-0006Kf-Na for emacs-devel@gnu.org; Sat, 06 Sep 2014 07:15:56 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:45820 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQDy8-0006KU-Cj for emacs-devel@gnu.org; Sat, 06 Sep 2014 07:15:48 -0400 Original-Received: (qmail 83473 invoked by uid 3782); 6 Sep 2014 11:15:46 -0000 Original-Received: from acm.muc.de (pD951985B.dip0.t-ipconnect.de [217.81.152.91]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 06 Sep 2014 13:15:44 +0200 Original-Received: (qmail 4078 invoked by uid 1000); 6 Sep 2014 11:10:26 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:174057 Archived-At: 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).