Re: Elisp native profiler

[Eli Zaretskii]

> Date: Mon, 01 Oct 2012 09:41:37 -0700
> From: Paul Eggert <address@hidden>
> CC: Stefan Monnier <address@hidden>, address@hidden, 
>  address@hidden
> 
> On 10/01/2012 07:48 AM, Eli Zaretskii wrote:
> > Here's one data point: on a Windows XP system based on Core i7 CPU at
> > 3.4GHz, running the profiler in an optimized build makes one of the 8
> > cores fully (90%) busy.
> 
> That doesn't sound good.  Is this the main thread, the one that
> runs the Emacs interpreter?

No, it isn't.  It's the additional thread that implements the
emulation of the Posix interval timers.

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.  But I don't think this is a big deal in this
case (the handler doesn't run Lisp), and even if it were, I don't know
how to run the handler in the context of the main thread.

> Then presumably it's running at roughly 10% of effectiveness.

No, it runs at 100%, because there are 7 more cores to do that.  Even
on a single-core multithreaded machine, which is quite a rarity today,
there will be another half-core to be used by the main thread.

> And if it's *not* the main thread, there are some race condition
> gotchas; the profiler signal handler should not run in parallel with
> the garbage collector.

The timer thread suspends the main thread (thus simulating a signal),
so the main thread cannot run at that time.

> It's quite worrisome that a simple counting operation, done every 15 ms,
> should nearly peg a core.  Something seems amiss.

I think this is because with the minimal sampling period I allow, the
timer thread almost never sleeps, and I think the signal handler does
quite a lot.  If I enlarge the sampling period to 30 ms, the thread
eats up only half a core, and with 50 ms it takes 10% of a core.

Or maybe I don't know how to write an efficient thread of this kind ;-)