Re: Making elp.el behave like a real profiler

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

Winston Carlile via "Emacs development discussions." [2022-08-15 12:22:54] wrote:
> I'm working on adding one level of context to function calls
> in ELP reports, looking for implementation and usability feedback.

Before we go any further: are you aware of the sampling based profiler
available via `M-x profiler-start`?

> 1) Is there a better way to programmatically access the call
>    stack than a dynamic binding hack?

There's `backtrace-frame(s)`, but I'm not sure it qualifies as "better".

> 2) How can I make the report more intuitive? Specifically
>    I'm worried about confusing people with the 0 call count
>    for f in the above example.

How 'bout:

    Function Name   Call Count
    g               1    ;; called once:
    `-?             1    ;; calls from functions not instrumented
    
    f               4    ;; called 4 times:
    `-g             1    ;; once from g
    `-f             3    ;; and 3 times from itself

Admittedly, this shows the "reverse" from what you currently show.
You'd have the property that for every function, the first line shows
the total of the subsequent lines.

For the other direction:

    Function Name   Call Count
    g               1    ;; called once
    `-f             1    ;; called f once
    
    f               4    ;; called 4 times:
    `-f             3    ;; called itself 3 times

In that version, for a given function, the first line's count is not
directly related to the other lines's count (it can be smaller or
larger).

> 3) Maybe a hashmap would be better than a plist when the
>    number of instrumented functions is large.

A plist is about as bad as it gets.  An alist would be at least a bit
more natural (plists only really make sense when they're written by
humans).

I'm not sure I understand the code correctly, but my quick reading of it
suggest you have O(N^2) calls to `new-infovec`, which seems like
a bad idea [ oh, and naming it without an `elp-` prefix is also a bad
idea) ] since the call graph is probably not that dense, so you'd be
better off allocating them more lazily.

If you keep the O(N^2) infovecs, then I'd recommend hashtables, indeed,
since every alist/plist will have N elements in it, here N will easily
grow to be too big for alist/plist (alist/plist work OK for smallish
number of elements only).


        Stefan