From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Avoiding loading cc-langs Date: Wed, 03 Sep 2014 22:38:09 -0400 Message-ID: References: <20140831212355.GA4401@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1409798328 17982 80.91.229.3 (4 Sep 2014 02:38:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Sep 2014 02:38:48 +0000 (UTC) Cc: Alan Mackenzie , Martin Stjernholm , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 04 04:38:42 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 1XPMwZ-0005UM-Li for ged-emacs-devel@m.gmane.org; Thu, 04 Sep 2014 04:38:39 +0200 Original-Received: from localhost ([::1]:48497 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPMwZ-0003mX-7f for ged-emacs-devel@m.gmane.org; Wed, 03 Sep 2014 22:38:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42080) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPMwE-0003g7-9c for emacs-devel@gnu.org; Wed, 03 Sep 2014 22:38:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPMw8-0000Oc-60 for emacs-devel@gnu.org; Wed, 03 Sep 2014 22:38:18 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:49340) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPMw7-0000OM-WD; Wed, 03 Sep 2014 22:38:12 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s842c9DF002369; Wed, 3 Sep 2014 22:38:09 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 4ADD16308B; Wed, 3 Sep 2014 22:38:09 -0400 (EDT) In-Reply-To: (Stefan Monnier's message of "Mon, 01 Sep 2014 18:43:37 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5053=0 X-NAI-Spam-Version: 2.3.0.9378 : core <5053> : inlines <1238> : streams <1280875> : uri <1810069> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:173999 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 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. 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. 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