From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: PURESIZE increased (again) Date: Fri, 28 Apr 2006 16:03:11 +0300 Message-ID: References: <87lku5u6tx.fsf@pacem.orebokech.com> <16F5541A-23E7-473C-A4D5-61E3B6930526@raeburn.org> <3BB432FA-E4F2-4477-8CA3-644673AC03BA@raeburn.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1146229484 11517 80.91.229.2 (28 Apr 2006 13:04:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 28 Apr 2006 13:04:44 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 28 15:04:43 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 1FZSe2-0001VW-5x for ged-emacs-devel@m.gmane.org; Fri, 28 Apr 2006 15:04:26 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FZSe1-0005yX-Q7 for ged-emacs-devel@m.gmane.org; Fri, 28 Apr 2006 09:04:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FZSdp-0005yR-Tc for emacs-devel@gnu.org; Fri, 28 Apr 2006 09:04:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FZSdl-0005yF-CO for emacs-devel@gnu.org; Fri, 28 Apr 2006 09:04:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FZSdl-0005yB-4y for emacs-devel@gnu.org; Fri, 28 Apr 2006 09:04:09 -0400 Original-Received: from [192.114.186.20] (helo=nitzan.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FZSgt-0001n5-CZ for emacs-devel@gnu.org; Fri, 28 Apr 2006 09:07:23 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-157-33.inter.net.il [80.230.157.33]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id DFR40445 (AUTH halo1); Fri, 28 Apr 2006 16:03:12 +0300 (IDT) Original-To: Ken Raeburn In-reply-to: <3BB432FA-E4F2-4477-8CA3-644673AC03BA@raeburn.org> (message from Ken Raeburn on Fri, 28 Apr 2006 03:07:35 -0400) 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:53547 Archived-At: > Cc: emacs-devel@gnu.org > From: Ken Raeburn > Date: Fri, 28 Apr 2006 03:07:35 -0400 > > > 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. Yes, if we find no other explanation, comparing .elc files would be the way to go. > 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. No need for binary search, I think: since we are debugging pure storage use, it's better to put a breakpoint on the functions that allocate space off pure[], and then xbacktrace will show what expression is being evaluated, while the C code will show how much pure space is being allocated. > If people want to expend that much effort on it, of course. 275KB of memory sounds like a good reason to me, but that's me.