GNU bug report logs - #17535
24.3.91; Problems with profiling memory

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Eli Zaretskii <eliz@HIDDEN>; dated Tue, 20 May 2014 17:03:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 17535 <at> debbugs.gnu.org:


Received: (at 17535) by debbugs.gnu.org; 29 May 2014 17:40:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 29 13:40:17 2014
Received: from localhost ([127.0.0.1]:36367 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Wq4JM-0003jG-HV
	for submit <at> debbugs.gnu.org; Thu, 29 May 2014 13:40:17 -0400
Received: from ironport2-out.teksavvy.com ([206.248.154.181]:55419)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1Wq4JK-0003ix-59
 for 17535 <at> debbugs.gnu.org; Thu, 29 May 2014 13:40:14 -0400
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArYGAIDvNVPO+IOj/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNJIgECNIZF456B4Q4BKkZgWqDTCE
X-IPAS-Result: ArYGAIDvNVPO+IOj/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNJIgECNIZF456B4Q4BKkZgWqDTCE
X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="64985831"
Received: from 206-248-131-163.dsl.teksavvy.com (HELO pastel.home)
 ([206.248.131.163])
 by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA;
 29 May 2014 13:40:08 -0400
Received: by pastel.home (Postfix, from userid 20848)
 id 325F0601BC; Thu, 29 May 2014 13:40:08 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#17535: 24.3.91; Problems with profiling memory
Message-ID: <jwv4n08h4sd.fsf-monnier+emacsbugs@HIDDEN>
References: <831tvobcym.fsf@HIDDEN>
 <jwva9acjn16.fsf-monnier+emacsbugs@HIDDEN> <83vbt0nt3i.fsf@HIDDEN>
 <jwvd2f8i4yz.fsf-monnier+emacsbugs@HIDDEN> <8338ftj1bb.fsf@HIDDEN>
 <jwv8upln5wh.fsf-monnier+emacsbugs@HIDDEN> <83d2ewh632.fsf@HIDDEN>
Date: Thu, 29 May 2014 13:40:08 -0400
In-Reply-To: <83d2ewh632.fsf@HIDDEN> (Eli Zaretskii's message of "Thu, 29 May
 2014 20:01:37 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 17535
Cc: tomo@HIDDEN, 17535 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

> If we don't count free as a negative allocation, can you envision a
> situation for which the memory profile, as we have it now, would be a
> useful tool?  Because I can't.

Beside a crutch for timer-less situations, this was also meant to help
debug high memory use by providing a profile of where memory allocation
tends to take place.

Counting freeing as 0 would make sense in this context.

Counting freeing as negative allocation is more tricky since it goes
towards trying to track "memory use" rather than "memory allocation",
but attributing memory use to particular code locations (or backtraces)
is often somewhere between hard and meaningless.

This said, "memory profiling" is a very hard subject, and I don't think
there's an approach that will always work better than another (or maybe
there is one, but it'd have to be tremendously more complex and costly
than the simplistic profiler we have), depending on the particulars of
the bug you're tracking.  So we should probably provide both options.


        Stefan




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17535; Package emacs. Full text available.

Message received at 17535 <at> debbugs.gnu.org:


Received: (at 17535) by debbugs.gnu.org; 29 May 2014 17:01:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 29 13:01:36 2014
Received: from localhost ([127.0.0.1]:36352 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Wq3hv-0002Sn-4R
	for submit <at> debbugs.gnu.org; Thu, 29 May 2014 13:01:35 -0400
Received: from mtaout24.012.net.il ([80.179.55.180]:55704)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1Wq3hr-0002SP-KX
 for 17535 <at> debbugs.gnu.org; Thu, 29 May 2014 13:01:33 -0400
Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il
 (HyperSendmail v2007.08) id <0N6C00J00HI30J00@HIDDEN> for
 17535 <at> debbugs.gnu.org; Thu, 29 May 2014 19:58:04 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0N6C00JMRHSR4L10@HIDDEN>; Thu, 29 May 2014 19:58:04 +0300 (IDT)
Date: Thu, 29 May 2014 20:01:37 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#17535: 24.3.91; Problems with profiling memory
In-reply-to: <jwv8upln5wh.fsf-monnier+emacsbugs@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Stefan Monnier <monnier@HIDDEN>
Message-id: <83d2ewh632.fsf@HIDDEN>
References: <831tvobcym.fsf@HIDDEN>
 <jwva9acjn16.fsf-monnier+emacsbugs@HIDDEN> <83vbt0nt3i.fsf@HIDDEN>
 <jwvd2f8i4yz.fsf-monnier+emacsbugs@HIDDEN> <8338ftj1bb.fsf@HIDDEN>
 <jwv8upln5wh.fsf-monnier+emacsbugs@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 17535
Cc: tomo@HIDDEN, 17535 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: Tomohiro Matsuyama <tomo@HIDDEN>,  17535 <at> debbugs.gnu.org
> Date: Wed, 28 May 2014 14:04:34 -0400
> 
> >> It only counts allocation, so "alloc+free+alloc" counts as 2 allocs.
> > Why doesn't it count a call to 'free' as a deallocation?
> 
> Original reason is that the memory profiler was mostly meant as a way to
> get profiling with the need for a timer (using memory allocation as
> a crude approximation of time).

But since now we do have timer-based CPU profiling, we no longer need
this approximation, right?

> Other reason is that deallocation largely takes place during GC and it's
> unclear to which functions/backtraces to attribute the corresponding
> negative (attributing them to the backtrace that happens to be current
> during GC would make the numbers pretty arbitrary).

First, there are quite a few places where we allocate and deallocate
memory for things other than Lisp objects.  Normally, such memory is
deallocated right away, or very soon, after it is no longer needed.
In those cases, we should attribute the memory freeing to the current
function/backtrace.

And second, I understand the limitations caused by GC, but I think we
should still attribute memory freed during GC to GC itself.  That way,
at least at some high enough level the positive and negative probes
will balance, and the memory profile won't look like one giant leak.

If we don't count free as a negative allocation, can you envision a
situation for which the memory profile, as we have it now, would be a
useful tool?  Because I can't.

> >   (defvar profiler-report-cpu-line-format
> >     '((50 left)
> >       (24 right ((19 right)
> > 		 (5 right)))))
> >
> >   (defvar profiler-report-memory-line-format
> >     '((55 left)
> >       (19 right ((14 right profiler-format-number)
> > 		 (5 right)))))
> >
> > Is it possible to have doc strings for these variables, or at least a
> > comment that explains this data structure, the meaning of each field,
> > and its possible values?  Otherwise, there's no way of adjusting them
> > when the report format is changed in some way.
> 
> I'm not familiar with this part of the code.  Hopefully Tomohiro can help.

I hope so too.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17535; Package emacs. Full text available.

Message received at 17535 <at> debbugs.gnu.org:


Received: (at 17535) by debbugs.gnu.org; 28 May 2014 23:45:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 28 19:45:25 2014
Received: from localhost ([127.0.0.1]:34929 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WpnXA-0002A2-Ec
	for submit <at> debbugs.gnu.org; Wed, 28 May 2014 19:45:24 -0400
Received: from ironport2-out.teksavvy.com ([206.248.154.181]:53861)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1WpnX7-00029p-7Z
 for 17535 <at> debbugs.gnu.org; Wed, 28 May 2014 19:45:22 -0400
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArYGAIDvNVNLd/fU/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNJIgECNIZF456B4Q4BKkZgWqDTCE
X-IPAS-Result: ArYGAIDvNVNLd/fU/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNJIgECNIZF456B4Q4BKkZgWqDTCE
X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="64908848"
Received: from 75-119-247-212.dsl.teksavvy.com (HELO pastel.home)
 ([75.119.247.212])
 by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA;
 28 May 2014 19:45:15 -0400
Received: by pastel.home (Postfix, from userid 20848)
 id 70DA4601CB; Wed, 28 May 2014 19:45:15 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#17535: 24.3.91; Problems with profiling memory
Message-ID: <jwvr43dlb7p.fsf-monnier+emacsbugs@HIDDEN>
References: <831tvobcym.fsf@HIDDEN>
 <jwva9acjn16.fsf-monnier+emacsbugs@HIDDEN> <83vbt0nt3i.fsf@HIDDEN>
 <jwvd2f8i4yz.fsf-monnier+emacsbugs@HIDDEN> <8338ftj1bb.fsf@HIDDEN>
 <jwv8upln5wh.fsf-monnier+emacsbugs@HIDDEN>
Date: Wed, 28 May 2014 19:45:15 -0400
In-Reply-To: <jwv8upln5wh.fsf-monnier+emacsbugs@HIDDEN> (Stefan Monnier's
 message of "Wed, 28 May 2014 14:04:34 -0400")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 17535
Cc: Tomohiro Matsuyama <tomo@HIDDEN>, 17535 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

> Original reason is that the memory profiler was mostly meant as a way to
> get profiling with the need for a timer (using memory allocation as
                ^^^^
               without
Duh!


        Stefan




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17535; Package emacs. Full text available.

Message received at 17535 <at> debbugs.gnu.org:


Received: (at 17535) by debbugs.gnu.org; 28 May 2014 18:04:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 28 14:04:52 2014
Received: from localhost ([127.0.0.1]:34810 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WpiDX-0001o9-ML
	for submit <at> debbugs.gnu.org; Wed, 28 May 2014 14:04:52 -0400
Received: from ironport2-out.teksavvy.com ([206.248.154.181]:59934)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1WpiDQ-0001nb-Mz
 for 17535 <at> debbugs.gnu.org; Wed, 28 May 2014 14:04:45 -0400
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArYGAIDvNVNLd/fU/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNJIgECNIZF456B4Q4BKkZgWqDTCE
X-IPAS-Result: ArYGAIDvNVNLd/fU/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNJIgECNIZF456B4Q4BKkZgWqDTCE
X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="64882865"
Received: from 75-119-247-212.dsl.teksavvy.com (HELO pastel.home)
 ([75.119.247.212])
 by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA;
 28 May 2014 14:04:34 -0400
Received: by pastel.home (Postfix, from userid 20848)
 id 6348B601CB; Wed, 28 May 2014 14:04:34 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#17535: 24.3.91; Problems with profiling memory
Message-ID: <jwv8upln5wh.fsf-monnier+emacsbugs@HIDDEN>
References: <831tvobcym.fsf@HIDDEN>
 <jwva9acjn16.fsf-monnier+emacsbugs@HIDDEN> <83vbt0nt3i.fsf@HIDDEN>
 <jwvd2f8i4yz.fsf-monnier+emacsbugs@HIDDEN> <8338ftj1bb.fsf@HIDDEN>
Date: Wed, 28 May 2014 14:04:34 -0400
In-Reply-To: <8338ftj1bb.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 28 May
 2014 19:49:28 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 17535
Cc: Tomohiro Matsuyama <tomo@HIDDEN>, 17535 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

>> It only counts allocation, so "alloc+free+alloc" counts as 2 allocs.
> Why doesn't it count a call to 'free' as a deallocation?

Original reason is that the memory profiler was mostly meant as a way to
get profiling with the need for a timer (using memory allocation as
a crude approximation of time).

Other reason is that deallocation largely takes place during GC and it's
unclear to which functions/backtraces to attribute the corresponding
negative (attributing them to the backtrace that happens to be current
during GC would make the numbers pretty arbitrary).

> This looks like we count memory we just swept (i.e. released) as an
> allocation.

Yes.

> Unless I'm missing something, that makes no sense.

IIRC this was motivated by the idea of using memory as a crude
approximation for time.

>   (defvar profiler-report-cpu-line-format
>     '((50 left)
>       (24 right ((19 right)
> 		 (5 right)))))
>
>   (defvar profiler-report-memory-line-format
>     '((55 left)
>       (19 right ((14 right profiler-format-number)
> 		 (5 right)))))
>
> Is it possible to have doc strings for these variables, or at least a
> comment that explains this data structure, the meaning of each field,
> and its possible values?  Otherwise, there's no way of adjusting them
> when the report format is changed in some way.

I'm not familiar with this part of the code.  Hopefully Tomohiro can help.

> mentioned in my original report) is worse than I thought: there are a
> lot of macros in profiler.el that are defined using cl-macs.el, and
> they all have the same problem: they have no doc strings, and "C-h f"
> cannot find their sources, which makes reading the code unbearably
> complicated.

That's something we need to fix in cl-macs.el, indeed.


        Stefan




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17535; Package emacs. Full text available.

Message received at 17535 <at> debbugs.gnu.org:


Received: (at 17535) by debbugs.gnu.org; 28 May 2014 16:49:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 28 12:49:38 2014
Received: from localhost ([127.0.0.1]:34773 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Wph2k-00085I-Nn
	for submit <at> debbugs.gnu.org; Wed, 28 May 2014 12:49:38 -0400
Received: from mtaout27.012.net.il ([80.179.55.183]:42666)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1Wph2f-00084x-EU
 for 17535 <at> debbugs.gnu.org; Wed, 28 May 2014 12:49:33 -0400
Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il
 (HyperSendmail v2007.08) id <0N6A00N00MIJ4O00@HIDDEN> for
 17535 <at> debbugs.gnu.org; Wed, 28 May 2014 19:46:11 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0N6A00LDNMKZXS10@HIDDEN>; Wed, 28 May 2014 19:46:11 +0300 (IDT)
Date: Wed, 28 May 2014 19:49:28 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#17535: 24.3.91; Problems with profiling memory
In-reply-to: <jwvd2f8i4yz.fsf-monnier+emacsbugs@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Stefan Monnier <monnier@HIDDEN>,
 Tomohiro Matsuyama <tomo@HIDDEN>
Message-id: <8338ftj1bb.fsf@HIDDEN>
References: <831tvobcym.fsf@HIDDEN>
 <jwva9acjn16.fsf-monnier+emacsbugs@HIDDEN> <83vbt0nt3i.fsf@HIDDEN>
 <jwvd2f8i4yz.fsf-monnier+emacsbugs@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 17535
Cc: 17535 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: 17535 <at> debbugs.gnu.org
> Date: Tue, 20 May 2014 16:16:13 -0400
> 
> >> > 2. How to interpret the "memory profile"?  What does a line such as
> >> >    this in the profile mean:
> >> >   - execute-extended-command                                  973,272  20%
> >> >    How were the 973,272 bytes counted, and what are they 20% of?  The
> >> >    ELisp manual, where this facility is described, does not explain
> >> >    how to interpret the profiles, and neither can I find anything
> >> >    about that in the doc strings.
> >> It's the number of bytes "allocated from the system" during execution of
> >> this function.
> > But these numbers are huge.  I have hard time believing that all those
> > bytes were allocated in just few minutes of an almost-idle Emacs.
> 
> It only counts allocation, so "alloc+free+alloc" counts as 2 allocs.

Why doesn't it count a call to 'free' as a deallocation?  Ignoring
freed memory makes the memory profiler much less useful than it could
have been; e.g., it would be impossible to look for leaks if releasing
memory is ignored.  Isn't it possible to call malloc_probe with a
negative argument?

Moreover, I don't understand this part of garbage-collect:

  /* Collect profiling data.  */
  if (profiler_memory_running)
    {
      size_t swept = 0;
      size_t tot_after = total_bytes_of_live_objects ();
      if (tot_before > tot_after)
	swept = tot_before - tot_after;
      malloc_probe (swept);
    }

This looks like we count memory we just swept (i.e. released) as an
allocation.  Unless I'm missing something, that makes no sense.

> >> This "allocation" is poorly defined: we don't track allocation of
> >> individual objects but of things like cons_blocks.
> > Do we only track allocations of Lisp objects, or just any calls to
> > xmalloc?
> 
> Can't remember.

I can now answer this myself: we track all calls to xmalloc, and also
all the allocating functions, like lisp_malloc, which call malloc
directly.  IOW, we track all memory allocations except direct calls to
mmap.

> >> >   etc.: I see no percentage numbers except 1%, 0%, and -1%.
> >> This is just most likely a wrap-around due to too-large integers.
> > Definitely.  I thought these were already fixed, but it looks they
> > aren't.  I will try to take a better look.  Are there any reasons not
> > to do this calculation in floating-point?
> 
> The raw counts need to be integers because we can't allocate during the
> sampling, but all the Elisp code could use floating point, I think.

Could someone please fix this?  Without a fix, the memory profiling is
simply useless.  It's too bad we released Emacs 24.3 like that, but at
least let's fix this in 24.4.

I tried a few relatively simple tricks, but couldn't make it work,
because using floats screws the report formatting.  Which brings me to
this snippet from profiler.el:

  (defvar profiler-report-cpu-line-format
    '((50 left)
      (24 right ((19 right)
		 (5 right)))))

  (defvar profiler-report-memory-line-format
    '((55 left)
      (19 right ((14 right profiler-format-number)
		 (5 right)))))

Is it possible to have doc strings for these variables, or at least a
comment that explains this data structure, the meaning of each field,
and its possible values?  Otherwise, there's no way of adjusting them
when the report format is changed in some way.

Finally, the situation with the doc strings (the first issue I
mentioned in my original report) is worse than I thought: there are a
lot of macros in profiler.el that are defined using cl-macs.el, and
they all have the same problem: they have no doc strings, and "C-h f"
cannot find their sources, which makes reading the code unbearably
complicated.

TIA




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17535; Package emacs. Full text available.

Message received at 17535 <at> debbugs.gnu.org:


Received: (at 17535) by debbugs.gnu.org; 20 May 2014 20:16:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 20 16:16:40 2014
Received: from localhost ([127.0.0.1]:54590 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WmqSm-0003BN-Bf
	for submit <at> debbugs.gnu.org; Tue, 20 May 2014 16:16:40 -0400
Received: from mercure.iro.umontreal.ca ([132.204.24.67]:41878)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1WmqSj-0003BE-Nv
 for 17535 <at> debbugs.gnu.org; Tue, 20 May 2014 16:16:38 -0400
Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca
 [132.204.27.50])
 by mercure.iro.umontreal.ca (Postfix) with ESMTP id 8956284DAB;
 Tue, 20 May 2014 16:16:37 -0400 (EDT)
Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca
 [132.204.27.242])
 by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id A7FA01E5B7C;
 Tue, 20 May 2014 16:16:13 -0400 (EDT)
Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848)
 id 8ED50B40F9; Tue, 20 May 2014 16:16:13 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#17535: 24.3.91; Problems with profiling memory
Message-ID: <jwvd2f8i4yz.fsf-monnier+emacsbugs@HIDDEN>
References: <831tvobcym.fsf@HIDDEN>
 <jwva9acjn16.fsf-monnier+emacsbugs@HIDDEN> <83vbt0nt3i.fsf@HIDDEN>
Date: Tue, 20 May 2014 16:16:13 -0400
In-Reply-To: <83vbt0nt3i.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 20 May
 2014 22:33:05 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-DIRO-MailScanner-Information: Please contact the ISP for more information
X-DIRO-MailScanner: Found to be clean
X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel,
 SpamAssassin (score=-2.82, requis 5, autolearn=not spam,
 ALL_TRUSTED -2.82, MC_TSTLAST 0.00)
X-DIRO-MailScanner-From: monnier@HIDDEN
X-Spam-Status: No
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 17535
Cc: 17535 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.0 (---)

>> > 2. How to interpret the "memory profile"?  What does a line such as
>> >    this in the profile mean:
>> >   - execute-extended-command                                  973,272  20%
>> >    How were the 973,272 bytes counted, and what are they 20% of?  The
>> >    ELisp manual, where this facility is described, does not explain
>> >    how to interpret the profiles, and neither can I find anything
>> >    about that in the doc strings.
>> It's the number of bytes "allocated from the system" during execution of
>> this function.
> But these numbers are huge.  I have hard time believing that all those
> bytes were allocated in just few minutes of an almost-idle Emacs.

It only counts allocation, so "alloc+free+alloc" counts as 2 allocs.
1MB of allocation over a few minutes of use doesn't sound particularly
odd to me.

>> This "allocation" is poorly defined: we don't track allocation of
>> individual objects but of things like cons_blocks.
> Do we only track allocations of Lisp objects, or just any calls to
> xmalloc?

Can't remember.

>> >   etc.: I see no percentage numbers except 1%, 0%, and -1%.
>> This is just most likely a wrap-around due to too-large integers.
> Definitely.  I thought these were already fixed, but it looks they
> aren't.  I will try to take a better look.  Are there any reasons not
> to do this calculation in floating-point?

The raw counts need to be integers because we can't allocate during the
sampling, but all the Elisp code could use floating point, I think.


        Stefan




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17535; Package emacs. Full text available.

Message received at 17535 <at> debbugs.gnu.org:


Received: (at 17535) by debbugs.gnu.org; 20 May 2014 19:33:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 20 15:33:06 2014
Received: from localhost ([127.0.0.1]:54560 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Wmpmc-0000yu-2g
	for submit <at> debbugs.gnu.org; Tue, 20 May 2014 15:33:06 -0400
Received: from mtaout25.012.net.il ([80.179.55.181]:35767)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1WmpmZ-0000yP-MI
 for 17535 <at> debbugs.gnu.org; Tue, 20 May 2014 15:33:05 -0400
Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il
 (HyperSendmail v2007.08) id <0N5W006000K06I00@HIDDEN> for
 17535 <at> debbugs.gnu.org; Tue, 20 May 2014 22:29:53 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0N5W003WQ0TSF130@HIDDEN>; Tue, 20 May 2014 22:29:53 +0300 (IDT)
Date: Tue, 20 May 2014 22:33:05 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#17535: 24.3.91; Problems with profiling memory
In-reply-to: <jwva9acjn16.fsf-monnier+emacsbugs@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Stefan Monnier <monnier@HIDDEN>
Message-id: <83vbt0nt3i.fsf@HIDDEN>
References: <831tvobcym.fsf@HIDDEN>
 <jwva9acjn16.fsf-monnier+emacsbugs@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 17535
Cc: 17535 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: 17535 <at> debbugs.gnu.org
> Date: Tue, 20 May 2014 15:01:34 -0400
> 
> > 2. How to interpret the "memory profile"?  What does a line such as
> >    this in the profile mean:
> >   - execute-extended-command                                  973,272  20%
> >    How were the 973,272 bytes counted, and what are they 20% of?  The
> >    ELisp manual, where this facility is described, does not explain
> >    how to interpret the profiles, and neither can I find anything
> >    about that in the doc strings.
> 
> It's the number of bytes "allocated from the system" during execution of
> this function.

But these numbers are huge.  I have hard time believing that all those
bytes were allocated in just few minutes of an almost-idle Emacs.

> This "allocation" is poorly defined: we don't track allocation of
> individual objects but of things like cons_blocks.

Do we only track allocations of Lisp objects, or just any calls to
xmalloc?

> >   etc.: I see no percentage numbers except 1%, 0%, and -1%.
> 
> This is just most likely a wrap-around due to too-large integers.

Definitely.  I thought these were already fixed, but it looks they
aren't.  I will try to take a better look.  Are there any reasons not
to do this calculation in floating-point?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17535; Package emacs. Full text available.

Message received at 17535 <at> debbugs.gnu.org:


Received: (at 17535) by debbugs.gnu.org; 20 May 2014 19:02:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 20 15:02:03 2014
Received: from localhost ([127.0.0.1]:54541 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WmpIZ-0000Fg-6G
	for submit <at> debbugs.gnu.org; Tue, 20 May 2014 15:02:03 -0400
Received: from mercure.iro.umontreal.ca ([132.204.24.67]:38287)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1WmpIW-0000FE-7A
 for 17535 <at> debbugs.gnu.org; Tue, 20 May 2014 15:02:00 -0400
Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca
 [132.204.27.50])
 by mercure.iro.umontreal.ca (Postfix) with ESMTP id CB7732413E;
 Tue, 20 May 2014 15:01:59 -0400 (EDT)
Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca
 [132.204.27.242])
 by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id E44CE1E5B7C;
 Tue, 20 May 2014 15:01:34 -0400 (EDT)
Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848)
 id C9D12B40F9; Tue, 20 May 2014 15:01:34 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#17535: 24.3.91; Problems with profiling memory
Message-ID: <jwva9acjn16.fsf-monnier+emacsbugs@HIDDEN>
References: <831tvobcym.fsf@HIDDEN>
Date: Tue, 20 May 2014 15:01:34 -0400
In-Reply-To: <831tvobcym.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 20 May
 2014 20:02:25 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-DIRO-MailScanner-Information: Please contact the ISP for more information
X-DIRO-MailScanner: Found to be clean
X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel,
 SpamAssassin (score=-2.82, requis 5, autolearn=not spam,
 ALL_TRUSTED -2.82, MC_TSTLAST 0.00)
X-DIRO-MailScanner-From: monnier@HIDDEN
X-Spam-Status: No
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 17535
Cc: 17535 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.0 (---)

>    Position cursor on "profiler-make-profile" and type "C-h f".  Emacs
>    pops up a *Help* buffer saying:
>      profiler-make-profile is a compiled Lisp function in `profiler.el'.
>      (profiler-make-profile &key TAG VERSION TYPE LOG TIMESTAMP DIFF-P)
>      This function has a compiler macro `profiler-make-profile--cmacro'.
>      Not documented.

>    Click on the "profiler.el" link in the *Help* buffer -- Emacs
>    displays an error message saying "Unable to find location in file"

Indeed.  Looks like a problem in cl-macs.el.

> 2. How to interpret the "memory profile"?  What does a line such as
>    this in the profile mean:
>   - execute-extended-command                                  973,272  20%
>    How were the 973,272 bytes counted, and what are they 20% of?  The
>    ELisp manual, where this facility is described, does not explain
>    how to interpret the profiles, and neither can I find anything
>    about that in the doc strings.

It's the number of bytes "allocated from the system" during execution of
this function.  This "allocation" is poorly defined: we don't track
allocation of individual objects but of things like cons_blocks.

>   etc.: I see no percentage numbers except 1%, 0%, and -1%.

This is just most likely a wrap-around due to too-large integers.


        Stefan




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17535; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 20 May 2014 17:02:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue May 20 13:02:56 2014
Received: from localhost ([127.0.0.1]:54492 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WmnRH-0005p3-EJ
	for submit <at> debbugs.gnu.org; Tue, 20 May 2014 13:02:55 -0400
Received: from eggs.gnu.org ([208.118.235.92]:54941)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1WmnRD-0005om-O9
 for submit <at> debbugs.gnu.org; Tue, 20 May 2014 13:02:53 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1WmnQy-0005wT-JD
 for submit <at> debbugs.gnu.org; Tue, 20 May 2014 13:02:46 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:36628)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1WmnQy-0005wP-Gj
 for submit <at> debbugs.gnu.org; Tue, 20 May 2014 13:02:36 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:56635)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1WmnQp-00083T-S2
 for bug-gnu-emacs@HIDDEN; Tue, 20 May 2014 13:02:36 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1WmnQh-0005uj-Cz
 for bug-gnu-emacs@HIDDEN; Tue, 20 May 2014 13:02:27 -0400
Received: from mtaout23.012.net.il ([80.179.55.175]:46971)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1WmnQh-0005sx-4l
 for bug-gnu-emacs@HIDDEN; Tue, 20 May 2014 13:02:19 -0400
Received: from conversion-daemon.a-mtaout23.012.net.il by
 a-mtaout23.012.net.il (HyperSendmail v2007.08) id
 <0N5V00E00THKNP00@HIDDEN> for bug-gnu-emacs@HIDDEN;
 Tue, 20 May 2014 20:02:17 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0N5V00ENTTZTJS70@HIDDEN> for bug-gnu-emacs@HIDDEN;
 Tue, 20 May 2014 20:02:17 +0300 (IDT)
Date: Tue, 20 May 2014 20:02:25 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: 24.3.91; Problems with profiling memory
X-012-Sender: halo1@HIDDEN
To: bug-gnu-emacs@HIDDEN
Message-id: <831tvobcym.fsf@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: Solaris 10
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.7 (-----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.7 (-----)


1. Visit profiler.el and go to this function:

    (defun profiler-cpu-profile ()
      "Return CPU profile."
      (when (profiler-running-p 'cpu)
	(profiler-make-profile
	 :type 'cpu
	 :timestamp (current-time)
	 :log (profiler-cpu-log))))

   Position cursor on "profiler-make-profile" and type "C-h f".  Emacs
   pops up a *Help* buffer saying:

     profiler-make-profile is a compiled Lisp function in `profiler.el'.

     (profiler-make-profile &key TAG VERSION TYPE LOG TIMESTAMP DIFF-P)

     This function has a compiler macro `profiler-make-profile--cmacro'.

     Not documented.

   Click on the "profiler.el" link in the *Help* buffer -- Emacs
   displays an error message saying "Unable to find location in file"

2. How to interpret the "memory profile"?  What does a line such as
   this in the profile mean:

  - execute-extended-command                                  973,272  20%

   How were the 973,272 bytes counted, and what are they 20% of?  The
   ELisp manual, where this facility is described, does not explain
   how to interpret the profiles, and neither can I find anything
   about that in the doc strings.

3. Displaying a memory profile after several minutes shows clear signs
   of overflow:

  - command-execute                                         151,652,741   0%
   - call-interactively                                     151,650,661   0%
    - dired-x-find-file                                      44,210,847   0%
     - find-file                                             44,210,847   0%
      - find-file-noselect                                   44,209,884   0%
  ...
	- normal-backup-enable-predicate                      7,091,148  -1%
	 - file-truename                                      7,091,148  -1%
	  - file-truename                                     5,910,436  -1%
	   - file-truename                                    4,729,872   1%
	    - file-truename                                   3,549,420   1%
	     - file-truename                                  2,369,208   0%
		file-truename                                 1,179,936   0%

  etc.: I see no percentage numbers except 1%, 0%, and -1%.




In GNU Emacs 24.3.91.12 (i686-pc-mingw32)
 of 2014-05-20 on HOME-C4E4A596F7
Repository revision: 117130 rgm@HIDDEN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --prefix=/d/usr --enable-checking=yes,glyphs 'CFLAGS=-O0
 -gdwarf-2 -g3''

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o r t - e m a <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process w32notify w32
multi-tty emacs)

Memory information:
((conses 8 74014 7322)
 (symbols 32 17470 0)
 (miscs 32 33 97)
 (strings 16 10775 4534)
 (string-bytes 1 269194)
 (vectors 8 9453)
 (vector-slots 4 372707 5780)
 (floats 8 57 68)
 (intervals 28 238 94)
 (buffers 508 11))




Acknowledgement sent to Eli Zaretskii <eliz@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#17535; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Fri, 31 Oct 2014 17:00:04 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.