Re: Elisp native profiler

[Stefan Monnier]

>> If it's common for 1ms to suffer from significant delays,
>> then it's a good argument for setting the default higher.
> I did a bit more investigation on this, on my host
> (x86-64, AMD Phenom II X4 910e, Fedora 17).  I instrumented
> trunk bzr 110342 to count total timer overruns, and did a
> CPU benchmark that took about 15.6 seconds when not profiling.

What is an "overrun" exactly?  Is it when the signal gets blocked
because we're still in the signal handler?  Or is it when the signal
gets sent "significantly" later than requested, e.g. because of internal
OS limits on timer granularity or something like that?


        Stefan