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: Saving more than 1MB when installed Date: Sat, 02 Jun 2012 15:50:37 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1338666648 25680 80.91.229.3 (2 Jun 2012 19:50:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 2 Jun 2012 19:50:48 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 02 21:50:47 2012 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 1SauLV-0007Vl-Nr for ged-emacs-devel@m.gmane.org; Sat, 02 Jun 2012 21:50:45 +0200 Original-Received: from localhost ([::1]:55914 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SauLV-0004CT-Fe for ged-emacs-devel@m.gmane.org; Sat, 02 Jun 2012 15:50:45 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45834) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SauLS-0004C4-Cd for emacs-devel@gnu.org; Sat, 02 Jun 2012 15:50:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SauLQ-0005Tc-Mv for emacs-devel@gnu.org; Sat, 02 Jun 2012 15:50:41 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:26020) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SauLQ-0005TU-IQ for emacs-devel@gnu.org; Sat, 02 Jun 2012 15:50:40 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09sr+UI/2dsb2JhbABEtBGBCIIVAQEEAVYoCws0EhQYDYhABboJjSaDHgOjM4FYgwU X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="187069932" Original-Received: from 108-175-229-8.dsl.teksavvy.com (HELO pastel.home) ([108.175.229.8]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 02 Jun 2012 15:50:38 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 0F19159607; Sat, 2 Jun 2012 15:50:38 -0400 (EDT) In-Reply-To: (Stefan Monnier's message of "Fri, 25 May 2012 21:10:38 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:150742 Archived-At: > Try the patch below. In my tests, adding the pre-loaded elc files in > DOC results in a much larger DOC file (2.4MB vs 650KB), but doesn't save > us anything in the `emacs' executable (neither pure space, nor live heap > or executable size). After further testing, it turns out that it does indeed save us about 24KB (on a 32bit system) of pure space (which corresponds to the about 3000 docstrings in the preloaded elc files). And the 2.4M-vs-650K is brought down to 2.4M-vs-1.6M after fixing my test to include loaddefs.el docstrings. So for now, I think I'll just leave this alone. I think a good direction for change would be to populate the DOC file directly from Lisp code rather than from make-docfile.c (e.g. from autoload.el and from the byte-compiler), so we don't need hacks in lread.c that ignore "things presumed to be docstrings that will hopefully later provided by Snarf-documentation" and also so we avoid duplicating the docstrings in loaddefs.el (and .elc files) and DOC. Actually, changing bytecomp.el to do that it pretty easy (no harder than what we currently do when outputting docstrings in a format sufficiently restricted for make-docfile to later find them), the only problem is in building the whole DOC file: currently we always rebuild it from scratch, whereas the byte-compiler could only incrementally update it, so we'd need to change the make-docfile side to update the file rather than erase&rebuild. Stefan