Re: Optimising Elisp code

[Barry Margolin]

In article <86r2h44fqg.fsf@zoho.com>, Emanuel Berg <moasen@zoho.com> 
wrote:

> Barry Margolin wrote:
> 
> > You can also define an inline function using
> > defsubst. From the Elisp manual:
> >
> > 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.
> 
> 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.
> 
> Yes, what does it mean that "the function's
> definition is open-coded into the caller"?
> 
> 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?

Yes, that's what "open-coded" means. 

> 
> > Making a function inline makes explicit calls
> > run faster.
> 
> Well, yeah, obviously since there is no second
> invocation with just the original function put
> onto the stack!
> 
> What are "explicit calls"? Regular calls,
> right? But then what are implicit calls?
> Anonymous functions? Or is an inline function
> being executed an implicit call to
> that function?

Calling the function with funcall or apply, e.g.

(funcall some-fun x y z)

The variable some-fun might contain an ordinary function or an inline 
function, but the compiler doesn't know what it will be so it can't 
expand it.

> 
> > 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.
> 
> Another good point, but that's obvious as well.
> 
> (Hey, for a person who doesn't understand this,
> I sure sound confident enough :))

Yep, you're picking it up OK.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***