[Top][All Lists]

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

Re: Elisp native profiler

From: Stefan Monnier
Subject: Re: Elisp native profiler
Date: Tue, 25 Sep 2012 20:53:33 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

>> > Shouldn't profiling use the same framework as atimers
>> > and the other async events?
>> We could do that, but to the extent that it is possible to do all the
>> work in the signal_handler while still being safe, I think it's
>> preferable.
> I bet the "read input in a signal handler" started that way, too.

AFAIK, the "read input in a signal handler" has been wrong/racy from
the beginning.  Tho, I guess at the beginning either the author didn't
know it was wrong, or he figured he could avoid the known problems with
it by playing with the malloc hooks.

But, yes, maybe at some we'll have to do it differently.  But doing it
differently means:
- doing potentially more work on QUIT (thus slowing down Emacs even
  when the profiler is not in use).
- suffer from a sampling bias (only the stack traces that lead to
  a QUIT can be sampled).
- miss some samples (because no QUIT occurred between the two signals).
- running QUIT more often (to reduce the bias and try and avoid missing
  some samples), again slowing down Emacs even when the profiler is not
  in use.
So I think for now I'd rather try and stick to "do it in the handler".


reply via email to

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