Re: Elisp native profiler

[Eli Zaretskii]

> Date: Fri, 28 Sep 2012 19:09:56 +0900
> From: Tomohiro Matsuyama <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> 
> > 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.
> How do you think about inserting a backtrace building code (like Ffuncall 
> does)
> into DEFUN macro expansion

I believe this is what Stefan was thinking of as well, yes.

> if specified so in configure script, for example?

Why doe we need a configure-time decision?  It is best to have this
decided at run time, because then you can ask any user to turn on
profiling when some performance problem is reported.

> This could be fully portable, but involves some overhead.

If the overhead can be avoided when not profiling (e.g., depending on
some global variable), that would be acceptable, I think.