From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.devel Subject: Re: size of emacs executable after unicode merge Date: Fri, 31 Oct 2008 15:30:59 -0400 Message-ID: References: <200805140351.m4E3pQuE004549@sallyv1.ics.uci.edu> <200805141652.m4EGqikr018644@sallyv1.ics.uci.edu> <200805151529.m4FFTlF1004684@sallyv1.ics.uci.edu> <482D8435.6060407@gnu.org> <20081030101819.GA15223@orion.lan> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1225481649 7534 80.91.229.12 (31 Oct 2008 19:34:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Oct 2008 19:34:09 +0000 (UTC) Cc: jasonr@gnu.org, dann@ics.uci.edu, evilborisnet@netscape.net, emanuele.giaquinta@gmail.com, emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 31 20:35:11 2008 connect(): Connection refused Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Kvzm2-00076z-3U for ged-emacs-devel@m.gmane.org; Fri, 31 Oct 2008 20:35:11 +0100 Original-Received: from localhost ([127.0.0.1]:53091 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kvzku-0006v3-Ci for ged-emacs-devel@m.gmane.org; Fri, 31 Oct 2008 15:34:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kvzkq-0006uC-PZ for emacs-devel@gnu.org; Fri, 31 Oct 2008 15:33:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kvzkp-0006tF-4E for emacs-devel@gnu.org; Fri, 31 Oct 2008 15:33:56 -0400 Original-Received: from [199.232.76.173] (port=56534 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kvzkp-0006tB-12 for emacs-devel@gnu.org; Fri, 31 Oct 2008 15:33:55 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:46069) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kvzko-0006nG-NC for emacs-devel@gnu.org; Fri, 31 Oct 2008 15:33:55 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1Kvzhz-0005MO-3a; Fri, 31 Oct 2008 15:30:59 -0400 In-reply-to: (message from Kenichi Handa on Fri, 31 Oct 2008 14:29:28 +0900) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:105224 Archived-At: Then, garbage-collect is called. After that, the living char-table is Vchar_unify_table only, and the contents is not that big because it maps upper area characters to charset, and each charset has linear upper area, thus most succeeding charaters have the same value. GC ought to free the space that was occupied by those tables. However, freeing the space does not necessarily reduce the size of the Emacs memory. It just puts freed objects in the free list. For instance, if the maps use cons cells, they will go on the free list but the memory will still be in the Emacs image. Maybe what is needed is to run a separate process to build the desired value for char-unify-table and store it in a file, and load just that file during building `emacs'.