emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: igc, macOS avoiding signals


From: Helmut Eller
Subject: Re: igc, macOS avoiding signals
Date: Fri, 03 Jan 2025 19:37:59 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

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.

(In eval_sub and Ffuncall, it would also help the profiler to move the
maybe_quit call forward before lisp_eval_depth--. This would only matter
for interpreted functions, not in byte compiled code.  Curiously,
apply_lambda doesn't call maybe_quit at all.)

Helmut


Attachment: 0001-Delay-processing-of-SIGPROF-to-the-next-safepoint.patch
Description: Text Data

Attachment: 0002-Call-maybe_quit-at-a-different-point-to-the-help-the.patch
Description: Text Data

Attachment: profiler-test.el
Description: application/emacs-lisp

Attachment: bar-0.report
Description: Text document

Attachment: bar-2.report
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]