help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Knowing where a function has been used (bis) [Was: Re: Optimising El


From: tomas
Subject: Re: Knowing where a function has been used (bis) [Was: Re: Optimising Elisp code]
Date: Sat, 6 Oct 2018 22:27:40 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat, Oct 06, 2018 at 09:55:09PM +0200, Garreau, Alexandre wrote:
> Le 06/10/2018 à 21h24, tomas@tuxteam.de a écrit :
> > On Sat, Oct 06, 2018 at 06:55:54PM +0200, Garreau, Alexandre wrote:
> >> Or would “reevaluate every function that where defined with the
> >> (now-redefined) inlined function inside” work too?
> >
> > Hmm. Not reevaluate, but recompile, and not "inside", but rather
> > "outside" -- like finding all places where this function was
> > inlined 
> 
> I don’t get how “outside” is the correct form here, as this is precisely
> what I was meaning: I mentioned it in my other message titled “Knowing
> where a function has been used (e.g. for optimizing)” (message-id: [0],
> url: [1]), as I found a such functionality, symetrical to
> find-definition, would be quite generally useful for lot of stuff.

Then I didn't get you right: I gather we both mean the "context" where
the function was "inlined into". If you're lucky, no optimization has
happened *after" you've inlined. Otherwise, you'll have to recompile
the whole context (i.e. parts of the caller).

> > and do some magic there.
> 
> What other kind of magic than (maybe recursively)
> reevaluating/recompiling could be needed there?

In the case of a redefinition of the inlined function you'll have to
find all call sites and do something.
> 
> > Perhaps doable, but not trivial.
> 
> I have really no precise idea of where and how is stored the place where
> each function was defined

Which functions you mean by "each function"? You mean the sites at which
the inlined function is "called" (i.e. inlined), I guess.

Well, I haven't a precise idea either, but for a pretty lucid description
(in the context of Guile, but with pointers to other implementations),
cf

  
https://wingolog.org/archives/2018/02/07/design-notes-on-inline-caches-in-guile

> >> Why “undo”? [...]

[...]

> So, except maybe wrt debugging (which there should imply reevaluation,

you mean "recompile"

> like with edebug-defun), reevaluating (or rather recompiling indeed,
> since afaiu then, simple evaluation will never optimize anything, unlike
> byte-compiling (right?)).

Not only debugging, but any kind of redefinition. Emacs lisp is a
dynamic language, and the users expect that when you redefine a
function, the new definition is active; unless the magic is under
user control (you've said "defmacro" or "def-inline", then you know
you've to recompile the callers), the run system has to manage the
mess, i.e. it has to remember all the sites where things have to
be inlined, like in the "inline cache" from the reference above.

Cheers
-- t

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]