[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, tomas@tuxteam.de 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.
- Re: Optimising Elisp code, (continued)
- Knowing where a function has been used (e.g. for optimizing) [Was: Re: Optimising Elisp code], Garreau, Alexandre, 2018/10/06
- Re: Optimising Elisp code, Stefan Monnier, 2018/10/06
- Re: Optimising Elisp code, Garreau, Alexandre, 2018/10/06
- Re: Optimising Elisp code, tomas, 2018/10/06
- Knowing where a function has been used (bis) [Was: Re: Optimising Elisp code], Garreau, Alexandre, 2018/10/06
- Re: Knowing where a function has been used (bis) [Was: Re: Optimising Elisp code], tomas, 2018/10/06
- Re: Knowing where a function has been used (bis) [Was: Re: Optimising Elisp code], Garreau, Alexandre, 2018/10/06
- Re: Knowing where a function has been used (bis) [Was: Re: Optimising Elisp code], tomas, 2018/10/07
- Re: Knowing where a function has been used (bis) [Was: Re: Optimising Elisp code],
Garreau, Alexandre <=
- Message not available
- Re: Knowing where a function has been used (bis) [Was: Re: Optimising Elisp code], Emanuel Berg, 2018/10/07
- Message not available
- Re: Knowing where a function has been used (bis) [Was: Re: Optimising Elisp code], Emanuel Berg, 2018/10/07
- Re: Knowing where a function has been used (bis) [Was: Re: Optimising Elisp code], Stefan Monnier, 2018/10/07
- Message not available
- Re: Knowing where a function has been used (bis) [Was: Re: Optimising Elisp code], Emanuel Berg, 2018/10/07
- Re: Optimising Elisp code [again], Garreau, Alexandre, 2018/10/07
- Message not available
- Re: Optimising Elisp code [again], Emanuel Berg, 2018/10/08
- Re: Optimising Elisp code [again], tomas, 2018/10/08
- Message not available
- Re: Optimising Elisp code [again], Barry Margolin, 2018/10/08
- Re: Optimising Elisp code [again], Emanuel Berg, 2018/10/09
- Re: Optimising Elisp code [again], Garreau, Alexandre, 2018/10/09