Re: Elisp native profiler

[Stefan Monnier <monnier@iro.umontreal.ca>]

> AFAIK, any backtrace facility is specific to the object file format
> and the debug info used by the platform.  Compiler optimizations and
> various non-local jumps complicate things a lot.  My suggestion would
> be not to go there, unless absolutely needed and desirable, because it
> most probably be in a constant need of maintenance to keep up with
> development of the underlying platform, compilers, etc.

Agreed.  Instead, I think we should just add some backtrace_list
registration to a few more functions (I've already added
Fgarbage_collect and redisplay_internal which covers the main points) if
we want more precision.  But since those don't come for free, we can
only do it for functions that take long enough that the impact can
be ignored.

> I think profiler-cpu-stop should revert the SIGPROF handler to its
> original value.  Currently, it only disables the interval timer, but
> leaves the SIGPROF handler pointed at its handler in profiler.c, which
> ain't right AFAICS.

Yes, that would be cleaner.

> Btw, the names profiler-cpu-* are not good names,

I'm not wedded to them, so if you have good alternatives, we can
change them.

> IMO: the "cpu" part is not correct.  How about profiler-funcall-* or
> profiler-execution-* instead?

Why?  The distinction between profiler-cpu-* and profiler-memory-* is
the "time basis", where one uses "cpu time" and the other "memory
allocation", hence the names.  "funcall" and "execution" both seem
completely unrelated.


        Stefan