[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Optimising Elisp code
From: |
Emanuel Berg |
Subject: |
Re: Optimising Elisp code |
Date: |
Fri, 05 Oct 2018 17:04:17 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) |
> This rings a bell from the C++ days
> when/where you could define a member function
> as "inline". That's all I remember, but maybe
> it was something similar to this? I think it
> amounted to, instead of making a call, that
> function was coded into the object itself,
> and for this reason it was suited for really
> short, simple functions. [...]
>
> If the caller is a function, does this mean
> instead of calling the other function, the
> other function's code is put into the first
> function so there isn't a second call but
> everything is executed in the first function?
OK, in C++ it works like this:
If a member function is defined within the
class definition (not recommended), or if it is
defined outside of it (recommended) with the
word "inline" preceding the return type, then
the function becomes an inline function.
What this means is that when the code is
compiled into machine code, instead of having
one place for the function, and jumping back
and forth every time that function is called,
the machine code for the inline function is
placed, duplicated wherever it is used.
So you get longer machine code, but faster,
since there is just constant execution for the
inline functions, without jumping back
and forth.
When should it be used? If the function is very
short, say 1-3 lines, the jumping back and
forth requires more machine instructions than
the function itself. Then the organizational
gain of having it neatly at one place is
diminished by the speed advantage of not having
to jump back and forth to that place all
the time.
"Make the common case fast, and the complicated
case work" -- M. Yoda
--
underground experts united
http://user.it.uu.se/~embe8573
- Optimising Elisp code, Davin Pearson, 2018/10/04
- Re: Optimising Elisp code, Davin Pearson, 2018/10/04
- Re: Optimising Elisp code, tomas, 2018/10/05
- Re: Optimising Elisp code, Barry Margolin, 2018/10/05
- Re: Optimising Elisp code, Emanuel Berg, 2018/10/05
- Re: Optimising Elisp code,
Emanuel Berg <=
- Re: Optimising Elisp code, Óscar Fuentes, 2018/10/05
- Message not available
- Re: Optimising Elisp code, Emanuel Berg, 2018/10/05
- Re: Optimising Elisp code, Óscar Fuentes, 2018/10/05
- Message not available
- Re: Optimising Elisp code, Emanuel Berg, 2018/10/05
- Re: Optimising Elisp code, Emanuel Berg, 2018/10/05
- Re: Optimising Elisp code, Emanuel Berg, 2018/10/05
- Re: Optimising Elisp code, Emanuel Berg, 2018/10/05
- Re: Optimising Elisp code, Stefan Monnier, 2018/10/05
- Message not available
- Re: Optimising Elisp code, Emanuel Berg, 2018/10/05
- Re: Optimising Elisp code, James K. Lowden, 2018/10/05