emacs-devel
[Top][All Lists]
Advanced

[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.



reply via email to

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