Re: Elisp native profiler

[Paul Eggert]

On 10/01/2012 03:37 AM, Eli Zaretskii wrote:

> That's a bug somewhere, isn't it?

It shouldn't dump core, true.  Someone with some free time should
probably look into that.  (I'm guessing it'll be me....)

> Will the signals caught during the period it was blocked
> be reissued, and if so, how many times?

On modern POSIXish systems, the pending SIGPROF signal is delivered
when the SIGPROF handler returns.  It's delivered just once.  There is
an overrun counter that will tell you how many instances of the signal
were discarded.

>From the user's point of view, if the sampling interval is too
short, Emacs spends all its time profiling and refuses to do
anything else.  I.e., it goes catatonic.

We currently don't let the user set the sampling interval to be less
than 1 ms, because our interface (perhaps unwisely) has millisecond
resolution.  As far as we know, 1 ms works on all POSIXish platforms,
and if so we don't have to worry about Emacs going catatonic, or about
overrun counts, or the like.  If we changed the API to let users
sample more often than 1 ms we would have to worry about this.

> Slower platforms should have their minimal supported interval in
> itimers be higher, no?

Typically the minimal supported interval is small enough so that an
Emacs process could easily go catatonic if we set the sampling
interval small enough (less than 1 ms).

> And 'setitimer' should round up the interval
> to the minimal supported value, shouldn't it?

Yes, but the value is pretty small.

> Default value is just that: the default.  If there are bad
> consequences possible when using very small sampling intervals,

Right now 1 ms is the default, and Stefan says that it works even on
his slow platform, and we're guessing that means that it works
everywhere of practical interest.