From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: igc statistics display Date: Fri, 10 Jan 2025 09:25:51 +0200 Message-ID: <86ldvj1668.fsf@gnu.org> References: <87frls9vxa.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20606"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 10 08:26:45 2025 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tW9Pp-0005CQ-0X for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Jan 2025 08:26:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tW9P3-0004fq-T3; Fri, 10 Jan 2025 02:25:57 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tW9P2-0004fb-Jc for emacs-devel@gnu.org; Fri, 10 Jan 2025 02:25:56 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tW9P1-0001Bj-3K; Fri, 10 Jan 2025 02:25:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=MV7q/VLBY1EUdAmPATY1A0zk2VA14v8gQFD2kXzl2vw=; b=Rk33gAkuctzVUYfbqMM2 +aFpwfeBBHgQpWcFcn4Bh+qzjvTtaNr09coqXJTr+Q163wxYu+UW8AenqrfDoog6M+Bo0qcvePHQH VUqXH/cvJCkk1H18zQm7mJL8k9+70PwcCQ45eZSEzlxW+CsA7/14Vp8RfoLpKtbby7LJafNg+ZxCQ pURmeD/nJiQZJMv+kucuMTeqxpEzjfPf/GkKTbkgbyqyuhZOrTbIEHFJyaABJXT7Saa2HDZl3DHWC kY+bVp5h2Mt/SKffz04oIylU4PbEnRuCEDycturxDjjnCqfoO0yRQPRLJRv09q6d4kudj8tKrMwS9 O6VaNWv0PQJUnQ==; In-Reply-To: (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Fri, 10 Jan 2025 07:26:55 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327828 Archived-At: > From: Gerd Möllmann > Cc: Emacs Devel > Date: Fri, 10 Jan 2025 07:26:55 +0100 > > BTW, found this > > https://docs.python.org/3/howto/instrumentation.html > > which basically says that Python can be built with Dtrace support that > one can use to monitor Python processes. > > I wonder if something like that wouldn't be interesting for Emacs also > beyond monitoring GC activity. We already have something similar for the display engine (trace-redisplay), and it is indeed very useful for investigating display problems. So yes, I think that having a similar facility for tracing GC in a build configured with --enable-checking=gc should be useful. However, it is possible that the means for activating the trace, whether it should be a command or a variable or something else, should be discussed, since GC is a more rare activity than redisplay, so maybe the same model is not optimal here. Whether this could be useful beyond GC is a separate issue. One complication is that different internal activities have different time frames and different traits, so I'm not sure they can all be usefully traced using the same commands/variables. In addition, the sheer flood of tracing outputs could well make this hard to use, even with today's large screens. So my gut feeling is that we should design the trace facilities separately for each kind of internal activities.