[Top][All Lists]

[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: Garreau, Alexandre
Subject: Re: Knowing where a function has been used (bis) [Was: Re: Optimising Elisp code]
Date: Sun, 07 Oct 2018 15:56:33 +0200
User-agent: Gnus (5.13), GNU Emacs 25.1.1 (i686-pc-linux-gnu)

Le 07/10/2018 à 10h10, a écrit :
> On Sat, Oct 06, 2018 at 11:42:12PM +0200, Garreau, Alexandre wrote:
> [...]
>> Not really, including this, but I was speaking about the find-definition
>> feature of emacs specifically, since afterwards I talk about a symmetric
>> feature, that is, store the list of symbols refered by each function, even 
>> (or
>> rather, especially) if it is compiled, in a place linked to each
>> function definition: so if the functions `f', `g' and `h' refer to `a',
>> having in something linked to the `a' symbol [...]
> OK, I roughly got your idea. I'm a bit out of time to discuss those
> things at depth (I'd have to do much more reading than I could ATM
> to be able to do more than just handwaving), but one last observation
> from me: I think what is going to kill you is the inherently dynamic
> nature of LISP

some calls will be more interesting to inline than others, or more
expensive, especially as their re-inlining (and recompilation of callee)
might be expensive, so the compiler could use that to choose whether
it’s interesting or not, I guess.

In the case in which it’s interesting, I think that *dynamically*
recompiling is enough.

> (think eval: once you reach such a point, potentially *every*
> function, even those not yet known at compile time, can be
> referenced).

eval will references what it gets as argument, when speaking of
inlining, we’re only speaking about body, not arguments: *here* maybe
(and I’m unsure) dynamic IC could do something, indeed.  But it’s not
what we’re talking about: at the most, if they were in lisp (in emacs
they’re not afaik), we could inline something such as apply and get eval
as a simply recursive function (maybe even tail-recursive in some cases?
or that would imply too much of optimized rearranging of calls
probably…) or something alike that would be useful.  But eval is in C
and if we talk about elisp optimization we only talk about stuff in
lisp:  afaiu there’s no way anything can be inlined inside eval, or eval
be inlined inside anything.

reply via email to

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