From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: PURESIZE increased (again) Date: Fri, 28 Apr 2006 03:07:35 -0400 Message-ID: <3BB432FA-E4F2-4477-8CA3-644673AC03BA@raeburn.org> References: <87lku5u6tx.fsf@pacem.orebokech.com> <16F5541A-23E7-473C-A4D5-61E3B6930526@raeburn.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1146208071 5809 80.91.229.2 (28 Apr 2006 07:07:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 28 Apr 2006 07:07:51 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 28 09:07:49 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FZN4u-00007o-M8 for ged-emacs-devel@m.gmane.org; Fri, 28 Apr 2006 09:07:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FZN4t-0000sc-P3 for ged-emacs-devel@m.gmane.org; Fri, 28 Apr 2006 03:07:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FZN4c-0000ru-KJ for emacs-devel@gnu.org; Fri, 28 Apr 2006 03:07:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FZN4a-0000r4-Jc for emacs-devel@gnu.org; Fri, 28 Apr 2006 03:07:30 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FZN4a-0000qv-EC for emacs-devel@gnu.org; Fri, 28 Apr 2006 03:07:28 -0400 Original-Received: from [204.127.200.84] (helo=sccrmhc14.comcast.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FZN7e-0000kD-9h; Fri, 28 Apr 2006 03:10:38 -0400 Original-Received: from raeburn.org (c-65-96-168-237.hsd1.ma.comcast.net[65.96.168.237]) by comcast.net (sccrmhc14) with ESMTP id <20060428070726014001v9nte>; Fri, 28 Apr 2006 07:07:26 +0000 Original-Received: from [18.101.0.226] (laptop.raeburn.org [18.101.0.226]) by raeburn.org (8.12.11/8.12.11) with ESMTP id k3S77QAr025152; Fri, 28 Apr 2006 03:07:26 -0400 (EDT) In-Reply-To: Original-To: Eli Zaretskii X-Mailer: Apple Mail (2.749.3) 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:53544 Archived-At: On Apr 28, 2006, at 01:29, Eli Zaretskii wrote: >> From: Ken Raeburn >> Date: Thu, 27 Apr 2006 18:24:55 -0400 >> >> The byte and object counts *should* be the same (uh, unless the >> pathnames to the elc files are stored somewhere but el file pathnames >> are not). (Actually, I should've said the increases in the byte and object counts, when each .elc file is loaded.) > Even if this is true (which I don't think it is), how can a stored > name explain 20KB of difference? It wouldn't, but if it does happen (and I don't think it does, either, but I don't recall for sure) it would be a reason for the numbers not to be *exactly* the same, so then a very small discrepancy wouldn't be a big problem. But like you say, I don't think it happens. >> It might also be useful to check that the .elc files you two are >> getting (you've both done "make bootstrap", right?) are actually >> similar. > > That's the point: how _could_ they be different? Barring the obvious, like local hacks affecting the byte-code optimizer, or some local bug causing character encoding conversions to be applied to byte-code strings, I have no idea. But since I have no other good idea how the 20K difference came up loading a .elc file, I figure breaking the problem down might help. For example: First, confirm that some file foo.elc to be loaded is (functionally) the same, and that it consume different amounts of storage, on the two systems. Then split it apart (binary search, one S-expression at a time, whatever) and see if there's some particular kind of expression in the .elc file that consumes different amounts of storage on the two systems. If we know what it is, perhaps we can figure out why it's handled differently. But if the files are different, then the problem isn't differing storage consumed by (identical) loaded objects, and we go off in a very different direction.... If people want to expend that much effort on it, of course. Ken