[Top][All Lists]

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

Re: Elisp native profiler

From: Eli Zaretskii
Subject: Re: Elisp native profiler
Date: Tue, 02 Oct 2012 19:14:44 +0200

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> Date: Tue, 02 Oct 2012 08:58:47 -0400
> >> > In a nutshell, that thread sleeps until the timer expiration, then
> >> > suspends the main thread, calls the SIGPROF handler, resumes the main
> >> > thread, and goes back to sleep.  The deviation from the Posix
> >> > semantics is that the handler runs in the context of a thread other
> >> > than the main thread.
> >> Isn't there another difference in that your code samples at a rate
> >> determined by the wall-clock time rather than the cpu-time of the process?
> > The timer thread is part of the process, so whenever it runs, the
> > process runs.
> > Or maybe I don't understand what you mean, exactly.
> If your profiler is set to sample every 10ms and your Emacs process uses
> 50% of the CPU, how many samples will you get after 1s: 100 or 50?

The answer is "it depends".  You should talk about threads, not
processes, since the emulated timer is a thread within the Emacs

But yes, if the main (Lisp) thread does not get CPU time at all, while
the timer thread does, then the current code will get 100 samples
after 1 sec (if such a situation can happen on modern multi-core
machines).  However, it never bothered me until now, because, as Paul
says, you cannot trust the timer to work on CPU clock of your process
anyway.  And on top of that, AFAIK you cannot even trust to get the
interval you asked for without checking with getitimer, see my other

If the decision is not to collect the actual CPU times in profiler.c's
SIGPROF handler, like I suggested, then I can adjust for the above
discrepancy by looking at the CPU time used by the main thread,
instead of looking at the wall-clock time, and simulating the timer
tick based on that.  (Assuming the relevant API is not too expensive,
that is.)

> And if Emacs is idle waiting for user input, after 1s will you get 100
> samples or 0?

Ah, but Emacs's idle loop is anything but idleness, as you well know.
Quite a few things get run while Emacs is "idle".

> Under GNU/Linux (at least with the "old" setitimer code) you'd have
> gotten 50 and 0 respectively.

I think this is sheer luck at best, even on GNU/Linux, and even then
when the system is not too loaded.

reply via email to

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