Knowing where a function has been used (e.g. for optimizing) [Was: Re: Optimising Elisp code]

[Garreau, Alexandre]

On 2018-10-05 at 10:28, Barry Margolin wrote:
> You can define bar as a macro -- those HAVE to be expanded at compile 
> time, since that's how they work.

But what’s the relationship since here, it’s not?

> You can also define an inline function using defsubst. From the Elisp 
> manual:

> Making a function inline makes explicit calls run faster. But it also 
> has disadvantages. For one thing, it reduces flexibility; if you change 
> the definition of the function, calls already inlined still use the old 
> definition until you recompile them.

So aren’t there any dynamical system that would keep a track of
dependencies so that to allow inlining while recompiling the appropriate
functions when changing definitions of inlined stuff?

> An inline function works just like an ordinary function except for one 
> thing: when you compile a call to the function, the function's 
> definition is open-coded into the caller.

Doesn’t lexical scoping also lead to that behavior?

> What you're describing is called inline expansion. AFAIK, the Elisp 
> compiler doesn't do this automatically.

Does it automatically for lexically scoped function definitions?

Is it only because then the behavior would differ and because there’s
currently no way to, say, tell to defun, each time it redefines
something that has been inlined, to also recompile every functions which
included it?

There’s already, for each currently defined function, a handy way to get
back to where it was defined.  But I always noticed this relation is
one-way: there’s no way, for each currently defined function, to get
back to where it was called.  I always missed it because it would gives
a quick way to look at exemples of how a function is used (examples are
the other great way of learning: inherenthly more imperfect than a
definition but quicker and easier), but I feel like, there, if it
existed, it would also allow to generalize some optimizations that
already are handy for compiled, non-dynamic code (because afaik
recursively do this and other expansions, reducing, simplification,
could lead to making abstraction free of performance overhead, right?).