Re: Knowing where a function has been used (bis) [Was: Re: Optimising Elisp code]

[Barry Margolin <barmar@alum.mit.edu>]

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

> Barry Margolin wrote:
> 
> >> If we are talking the insanely long
> >> functions of Gnus, if the funcall overhead
> >> is the reason for that, I don't see why
> >> modularization plus inlining couldn't be one
> >> puzzle piece of the remedy.
> >
> > If a function is "insanely long" then
> > inlining will have negligible effect.
> > Funcall overhead is only relevant if the
> > function is really short, so it spends nearly
> > as much time calling the function as doing
> > the actual work of the function, AND you call
> > the function frequently enough that this
> > overhead adds up to something significant.
> 
> The insanely long functions would be shorter if
> they, instead of doing one million things,
> called other functions to help them with that.
> This isn't done because it isn't fast enough.
> But if inline works as you describe it, some of
> that code could in fact be moved out of the
> insanely long function, while still not slowing
> it down with funcall overhead.

Long functions are often long because of complex logic, which can be 
hard to extract into separate functions.

Also, we tend to extract code into separate functions only when there's 
some logic to it -- it has to have a meaningful identity outside the 
function where it exists. If a function can only be used in one place, 
and refers to lots of the variables in that caller, then it's often hard 
to justify splitting it out -- it actually makes things more confusing 
because the modularity doesn't make sense.

I doubt that anyone makes decision about whether to split large 
functions into separate functions based on the overhead of function 
calling.

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