Re: List of all functions (recursively) called by a function?

[Pascal J. Bourguignon]

Elena <egarrulo@gmail.com> writes:

> On Nov 30, 1:34 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
> wrote:
>> Elena <egarr...@gmail.com> writes:
>> > is there a way to get the list of all functions (recursively) called
>> > by a function?
>>
>> Probably.  I don't know if there is already a tool to build the call
>> graph for emacs lisp, but these tools exist for various languages
>> including lisps.
>
> I can't find any.  However, there are dependencies checkers for
> packages.  I guess their code can be adapted.  I'll give that a try.
>
>>
>> > Once a while, my Emacs hangs.  It usually happens when interacting
>> > with the file-system.  I've tried isolating the function which causes
>> > the hang, by means of  `keyboard-quit' after having set `debug-on-
>> > error' to true, but without success, since `keyboard-quit' does not
>> > break the hang.  Therefore, I've been thinking about running a
>> > profiler on functions during which the hang happens.  One of these
>> > functions is `ido-find-file'.  The profiling package "elp" has
>> > correctly identified this function as spending a lot of time.  Now,
>> > I'd like to profile all functions called by `ido-find-file' to catch
>> > the misbehaving one.
>>
>> > Any pointers?  Thanks.
>>
>> You would need a debugger such as:
>> http://video.google.com/videoplay?docid=3897010229726822034#
>> Perhaps you'd be interested in writing one for emacs lisp?
>
> I cannot check out that video now, thus I cannot answer here.

Be sure to watch it eventually, it's impressive.


> However, if everything else fails, I think I'll help the mantainer of
> Emacs Native Profiler to port his efforts to Windows.

Usually, profilers work quite differently from back-in-time debuggers,
since they usually take a stockastic approach.

On the other hand, since we have a VM, it should be rather easy to
implement a back-in-time debugger for emacs.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.