[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: igc, macOS avoiding signals
From: |
Eli Zaretskii |
Subject: |
Re: igc, macOS avoiding signals |
Date: |
Fri, 03 Jan 2025 21:55:45 +0200 |
> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Pip Cet <pipcet@protonmail.com>, gerd.moellmann@gmail.com,
> spd@toadstyle.org, emacs-devel@gnu.org
> Date: Fri, 03 Jan 2025 19:37:59 +0100
>
> On Tue, Dec 31 2024, Eli Zaretskii wrote:
> > We'd need to add a new function to process_pending_signals, which
> > would process SIGPROF and maybe also SIGALRM. The signal handlers for
> > those would then only set a flag (not pending_signals, some other
> > flag).
>
> I implemented this with the two attached patches. The trouble is that,
> the recorded backtraces are not same. This can be seen by looking at
> the call tree produced by profiler.el and the attached profiler-test.el.
> When add_sample is called in the signal handler, then the call tree for
> the foo example looks so:
>
> ...
> 1986 100% main
> 1986 100% record-samples
> 1986 100% foo
> 1074 54% float-time
> 0 0% ...
>
> When add_sample is called from process_pending_signals, it looks like
> this:
>
> ...
> 1986 100% main
> 1986 100% record-samples
> 1986 100% foo
> 0 0% ...
>
> Not the absence of float-time. The reason for this is, that in
> bytecode.c, maybe_quit is called before the function is pushed to the
> backtrace with record_in_backtrace. In the second patch, I moved this
> call forward to before the function is popped with lisp_eval_depth--.
> With this patch, the call tree includes float-time again:
>
> ...
> 1989 100% main
> 1989 100% record-samples
> 1989 100% foo
> 1981 99% float-time
> 0 0% ...
>
> However, float-time has now 99% as opposed to 54% in the first call
> tree.
>
> A more complex pair of call trees is attached in the files
> bar-0.report and bar-2.report. A significant difference there is
> in this section:
>
> ...
> 781 73% animate-place-char
> 19 1% delete-char
> 16 1% floor
> 4 0% undo-auto--undoable-change
> 4 0% undo-auto--boundary-ensure-timer
> 96 9% insert-char
> 14 1% undo-auto--undoable-change
> 6 0% undo-auto--boundary-ensure-timer
> 5 0% beginning-of-line
> 232 21% move-to-column
> ...
>
> compared to the version with both patches applied:
>
> ...
> 693 72% animate-place-char
> 32 3% delete-char
> 29 3% window-start
> 43 4% insert-char
> 309 32% move-to-column
> 222 23% beginning-of-line
> 8 0% undo-auto--undoable-change
> 8 0% undo-auto--boundary-ensure-timer
> 8 0% run-at-time
> 8 0% timer-set-function
> 8 0% timerp
> 8 0% vectorp
> ...
>
> E.g. the percentage attributed to beginning-of-line is quite different
> in those two versions (23% and 0%).
>
> I'm not sure if those differences are acceptable. I also have no good
> idea how to reduce it, except inserting more calls to maybe_quit.
Thanks.
I guess this means we don't call maybe_quit frequently enough to
produce accurate profiles using this method.
- Re: igc, macOS avoiding signals, Helmut Eller, 2025/01/03
- Re: igc, macOS avoiding signals,
Eli Zaretskii <=
- Re: igc, macOS avoiding signals, Pip Cet, 2025/01/04
- Re: igc, macOS avoiding signals, Gerd Möllmann, 2025/01/04
- Re: igc, macOS avoiding signals, Gerd Möllmann, 2025/01/04
- Re: igc, macOS avoiding signals, Eli Zaretskii, 2025/01/04
- Re: igc, macOS avoiding signals, Gerd Möllmann, 2025/01/04
- Re: igc, macOS avoiding signals, Eli Zaretskii, 2025/01/04
- Re: igc, macOS avoiding signals, Gerd Möllmann, 2025/01/04
Re: igc, macOS avoiding signals, Helmut Eller, 2025/01/04