igc statistics display

igc statistics display

[Gerd Möllmann]

The branch scratch/igc has an igc.el which contains a couple of
functions with which one can inspect some innards if the GC, igc-stats
and igc-root-stats.

That's useful I think, but I'd like to extend it so that one can see
what happens over a longer period of time. For that purpose, I've added
igc-start/stop-collecting-stats a while ago which collects CSV data in a
buffer every N seconds. I can import that CSV into a sqlite table and
display a (very simple) plot of a query, say what's happening for
conses, using DB Browser,

That as background.

What I'm looking for is something better. Ideally, I imagine something
working online, i.e. instead of writing CSV, I would send something to a
monitor program storing that data, and displaying plots of my choice.

I thought someone might have a similar use-case, and could give advice
what to use for something like that, preferably a small implementation
resistance, of course. Or, might be interesting helping, which would of
course be even better, because I'm a bit out of my comfort zone here.

Re: igc statistics display

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Thu, 09 Jan 2025 09:22:10 +0100
> 
> What I'm looking for is something better. Ideally, I imagine something
> working online, i.e. instead of writing CSV, I would send something to a
> monitor program storing that data, and displaying plots of my choice.
> 
> I thought someone might have a similar use-case, and could give advice
> what to use for something like that, preferably a small implementation
> resistance, of course. Or, might be interesting helping, which would of
> course be even better, because I'm a bit out of my comfort zone here.

AFAIK, we use gnuplot for graphics.  There are interfaces for that in
Calc and in Org.

There's also chart.el, but it can only draw bar charts.

Re: igc statistics display

[Helmut Eller]

On Thu, Jan 09 2025, Gerd Möllmann wrote:

> I thought someone might have a similar use-case, and could give advice
> what to use for something like that, preferably a small implementation
> resistance, of course. Or, might be interesting helping, which would of
> course be even better, because I'm a bit out of my comfort zone here.

I'm currently learning a bit to use systemtap.  It seems that systemtap
is similar to dtrace, which I think is available for macOS.  Maybe you
could try that.  Unfortunately, systemtap seems to be targeted more at
kernel code than at user space code.

I mostly follow the advice from here:
https://www.brendangregg.com/blog/2015-07-08/choosing-a-linux-tracer.html

Helmut

Re: igc statistics display

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Thu, Jan 09 2025, Gerd Möllmann wrote:
>
>> I thought someone might have a similar use-case, and could give advice
>> what to use for something like that, preferably a small implementation
>> resistance, of course. Or, might be interesting helping, which would of
>> course be even better, because I'm a bit out of my comfort zone here.
>
> I'm currently learning a bit to use systemtap.  It seems that systemtap
> is similar to dtrace, which I think is available for macOS.  Maybe you
> could try that.  Unfortunately, systemtap seems to be targeted more at
> kernel code than at user space code.
>
> I mostly follow the advice from here:
> https://www.brendangregg.com/blog/2015-07-08/choosing-a-linux-tracer.html
>
> Helmut

That's an interesting thought! Maybe one could generate perf events, or
what they are called. don't remember much about dtrace. And I would have
to check what macOS allows one to do without disabling security measures
which itself would require a reboot in recovery mode. Very interesting!

And one would of course need some nice interface for displaying events.

Thanks!

Re: igc statistics display

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Helmut Eller <eller.helmut@gmail.com> writes:
>
>> On Thu, Jan 09 2025, Gerd Möllmann wrote:
>>
>>> I thought someone might have a similar use-case, and could give advice
>>> what to use for something like that, preferably a small implementation
>>> resistance, of course. Or, might be interesting helping, which would of
>>> course be even better, because I'm a bit out of my comfort zone here.
>>
>> I'm currently learning a bit to use systemtap.  It seems that systemtap
>> is similar to dtrace, which I think is available for macOS.  Maybe you
>> could try that.  Unfortunately, systemtap seems to be targeted more at
>> kernel code than at user space code.
>>
>> I mostly follow the advice from here:
>> https://www.brendangregg.com/blog/2015-07-08/choosing-a-linux-tracer.html
>>
>> Helmut
>
> That's an interesting thought! Maybe one could generate perf events, or
> what they are called. don't remember much about dtrace. And I would have
> to check what macOS allows one to do without disabling security measures
> which itself would require a reboot in recovery mode. Very interesting!
>
> And one would of course need some nice interface for displaying events.
>
> Thanks!

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.

Re: igc statistics display

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 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.

Re: igc statistics display

[Helmut Eller]

On Fri, Jan 10 2025, Gerd Möllmann wrote:

> I wonder if something like that wouldn't be interesting for Emacs also
> beyond monitoring GC activity.

There are many potentially interesting events
  - begin/end of a command
  - begin/end of a redisplay
  - cache misses (regexp cache, charpos cache ..)
  - begin/end of interval rebalancing?
  - call/return of Lisp functions

It's a bit annyoing that drace/systemtap needs special permissions.  In
theory, systemtap has a "dyninst runtime" that uses ptrace instead of
uprobes and hence would not need special permissions (at least not more
than gdb).  In practice, the dyninst runtime doesn't seem to work yet:
it exist with a segfault.

It would also be useful to have some helper functions (called tapsets in
systemtap) to write dtrace/systemtap scripts, e.g. accessing symbol-name
etc.

Helmut

Re: igc statistics display

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> Date: Fri, 10 Jan 2025 08:31:29 +0100
> 
> On Fri, Jan 10 2025, Gerd Möllmann wrote:
> 
> > I wonder if something like that wouldn't be interesting for Emacs also
> > beyond monitoring GC activity.
> 
> There are many potentially interesting events
>   - begin/end of a command
>   - begin/end of a redisplay
>   - cache misses (regexp cache, charpos cache ..)
>   - begin/end of interval rebalancing?
>   - call/return of Lisp functions
> 
> It's a bit annyoing that drace/systemtap needs special permissions.  In
> theory, systemtap has a "dyninst runtime" that uses ptrace instead of
> uprobes and hence would not need special permissions (at least not more
> than gdb).  In practice, the dyninst runtime doesn't seem to work yet:
> it exist with a segfault.
> 
> It would also be useful to have some helper functions (called tapsets in
> systemtap) to write dtrace/systemtap scripts, e.g. accessing symbol-name
> etc.

SystemTap is not the ideal means for such a facility.  Its only
significant advantage is that it's supported by GDB.  But its huge
disadvantage is that it's a Linux-only facility.

In addition, I feel that this is too low-level for our purposes.  We
need something more akin to trace-redisplay.

Re: igc statistics display

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> SystemTap is not the ideal means for such a facility.  Its only
> significant advantage is that it's supported by GDB.  But its huge
> disadvantage is that it's a Linux-only facility.
>
> In addition, I feel that this is too low-level for our purposes.  We
> need something more akin to trace-redisplay.

I must say upfront that I've only read about dtrace for a couple hours
and asked Gemini a few questions. From that, my understanding is that an
application can generate its own application-specific events that carry
additional data, including strings, int, floats, and so on, structs (not
sure if I believe Gemini in that case, but who knows). (Helmut, please
correct me if that's wrong.)

If that's true, one could include the info needed for a redisplay trace
in the event.

What events to generate for what is of course another question.

Re: igc statistics display

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Helmut Eller <eller.helmut@gmail.com>,  emacs-devel@gnu.org
> Date: Fri, 10 Jan 2025 09:05:14 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > SystemTap is not the ideal means for such a facility.  Its only
> > significant advantage is that it's supported by GDB.  But its huge
> > disadvantage is that it's a Linux-only facility.
> >
> > In addition, I feel that this is too low-level for our purposes.  We
> > need something more akin to trace-redisplay.
> 
> I must say upfront that I've only read about dtrace for a couple hours
> and asked Gemini a few questions. From that, my understanding is that an
> application can generate its own application-specific events that carry
> additional data, including strings, int, floats, and so on, structs (not
> sure if I believe Gemini in that case, but who knows). (Helmut, please
> correct me if that's wrong.)
> 
> If that's true, one could include the info needed for a redisplay trace
> in the event.
> 
> What events to generate for what is of course another question.

If we need to produce our own data, then how is using these facilities
more useful than just printing the stuff to stderr?

Re: igc statistics display

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> 
>> What events to generate for what is of course another question.
>
> If we need to produce our own data, then how is using these facilities
> more useful than just printing the stuff to stderr?

I think Helmut answered that. It's being cheap when not used, for
example. But I'm not proposing anything, at least so far, new branch
incoming. Just a joke :-).

Re: igc statistics display

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 10 Jan 2025 10:02:22 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 
> >> What events to generate for what is of course another question.
> >
> > If we need to produce our own data, then how is using these facilities
> > more useful than just printing the stuff to stderr?
> 
> I think Helmut answered that. It's being cheap when not used, for
> example.

Neither are the printf's, if conditioned by some variable.

Re: igc statistics display

[Helmut Eller]

On Fri, Jan 10 2025, Gerd Möllmann wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>> SystemTap is not the ideal means for such a facility.  Its only
>> significant advantage is that it's supported by GDB.  But its huge
>> disadvantage is that it's a Linux-only facility.

I think drrace is also available for Windows.

>> In addition, I feel that this is too low-level for our purposes.  We
>> need something more akin to trace-redisplay.
>
> I must say upfront that I've only read about dtrace for a couple hours
> and asked Gemini a few questions. From that, my understanding is that an
> application can generate its own application-specific events that carry
> additional data, including strings, int, floats, and so on, structs (not
> sure if I believe Gemini in that case, but who knows). (Helmut, please
> correct me if that's wrong.)

Applications can define "static trace points".  In practice, that means
the application has macro calls like DTRACE_PROBE(name, arg1, arg2..)
in the source code at interesting places.  Obviously, the same macro
could be configured to work with dtrace or systemtap or something else.

An advantage of tools like dtrace and systemtap is that they can patch
code: static trace points are nop instructions, until activated.  So
very cheap, if not used.  Ironically, that's almost impossible to do by
the application itself.

Static trace points are useful, but with dtrace/systemtap it's also
possible to set trace points by line number, as in gdb.

Helmut

Re: igc statistics display

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Fri, Jan 10 2025, Gerd Möllmann wrote:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>> SystemTap is not the ideal means for such a facility.  Its only
>>> significant advantage is that it's supported by GDB.  But its huge
>>> disadvantage is that it's a Linux-only facility.
>
> I think drrace is also available for Windows.
>
>>> In addition, I feel that this is too low-level for our purposes.  We
>>> need something more akin to trace-redisplay.
>>
>> I must say upfront that I've only read about dtrace for a couple hours
>> and asked Gemini a few questions. From that, my understanding is that an
>> application can generate its own application-specific events that carry
>> additional data, including strings, int, floats, and so on, structs (not
>> sure if I believe Gemini in that case, but who knows). (Helmut, please
>> correct me if that's wrong.)
>
> Applications can define "static trace points".  In practice, that means
> the application has macro calls like DTRACE_PROBE(name, arg1, arg2..)
> in the source code at interesting places.  Obviously, the same macro
> could be configured to work with dtrace or systemtap or something else.
>
> An advantage of tools like dtrace and systemtap is that they can patch
> code: static trace points are nop instructions, until activated.  So
> very cheap, if not used.  Ironically, that's almost impossible to do by
> the application itself.
>
> Static trace points are useful, but with dtrace/systemtap it's also
> possible to set trace points by line number, as in gdb.
>
> Helmut

Thanks, very interesginb!