inline

inline

[Emanuel Berg]

On gnu.emacs.help, there has been a long
discussion on inlining functions.

Just now, I wrote

    If you have studied the Gnus source code,
    you find that the defuns are insanely long.
    They go on all but forever. This is because
    Gnus is already slow, and perhaps Elisp is
    as well, so they don't want to brake it up
    into modules (smaller defuns) because then
    it would require the funcall overhead.
    Perhaps Gnus would benefit from
    inlining stuff?

But be sure to check out the entire thread.
There has been lots of changes to the subject
line so there are several threads all dealing
with the inline stuff.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: inline

[Eric Abrahamsen]

Emanuel Berg <moasen@zoho.com> writes:

> On gnu.emacs.help, there has been a long
> discussion on inlining functions.
>
> Just now, I wrote
>
>     If you have studied the Gnus source code,
>     you find that the defuns are insanely long.
>     They go on all but forever. This is because
>     Gnus is already slow, and perhaps Elisp is
>     as well, so they don't want to brake it up
>     into modules (smaller defuns) because then
>     it would require the funcall overhead.
>     Perhaps Gnus would benefit from
>     inlining stuff?
>
> But be sure to check out the entire thread.
> There has been lots of changes to the subject
> line so there are several threads all dealing
> with the inline stuff.

FWIW, I think Gnus would gain the most not by inlining more code, but by
adjusting its data structures, and introducing more caching at higher
levels. So much of the code is simply boilerplate for finding things, or
gathering data together, and doing it repeatedly. I think that's where
most of the win would be. 

Re: inline

[Garreau, Alexandre]

Le 08/10/2018 à 10h06, Eric Abrahamsen a écrit :
> Emanuel Berg <moasen@zoho.com> writes:
>> On gnu.emacs.help, there has been a long
>> discussion on inlining functions.
>>
>> Just now, I wrote
>>
>>     If you have studied the Gnus source code, you find that the
>>     defuns are insanely long.  They go on all but forever. This is
>>     because Gnus is already slow, and perhaps Elisp is as well, so
>>     they don't want to brake it up into modules (smaller defuns)
>>     because then it would require the funcall overhead.  Perhaps Gnus
>>     would benefit from inlining stuff?
>>
>> But be sure to check out the entire thread.  There has been lots of
>> changes to the subject line so there are several threads all dealing
>> with the inline stuff.
>
> FWIW, I think Gnus would gain the most not by inlining more code, but
> by adjusting its data structures, and introducing more caching at
> higher levels. So much of the code is simply boilerplate for finding
> things, or gathering data together, and doing it repeatedly. I think
> that's where most of the win would be.

So, in the aforementioned discussion, in the end I was right: I/O plays
a bigger role there than function call overhead, right?

So maybe “breaking the defuns into [parts]”, if done correctly, wouldn’t
“make it even slower”?

PS: I subscribed just in time to see a first answer to that thread! \o/

Re: inline

[Eric Abrahamsen]

"Garreau, Alexandre" <galex-713@galex-713.eu> writes:

> Le 08/10/2018 à 10h06, Eric Abrahamsen a écrit :
>> Emanuel Berg <moasen@zoho.com> writes:
>>> On gnu.emacs.help, there has been a long
>>> discussion on inlining functions.
>>>
>>> Just now, I wrote
>>>
>>>     If you have studied the Gnus source code, you find that the
>>>     defuns are insanely long.  They go on all but forever. This is
>>>     because Gnus is already slow, and perhaps Elisp is as well, so
>>>     they don't want to brake it up into modules (smaller defuns)
>>>     because then it would require the funcall overhead.  Perhaps Gnus
>>>     would benefit from inlining stuff?
>>>
>>> But be sure to check out the entire thread.  There has been lots of
>>> changes to the subject line so there are several threads all dealing
>>> with the inline stuff.
>>
>> FWIW, I think Gnus would gain the most not by inlining more code, but
>> by adjusting its data structures, and introducing more caching at
>> higher levels. So much of the code is simply boilerplate for finding
>> things, or gathering data together, and doing it repeatedly. I think
>> that's where most of the win would be.
>
> So, in the aforementioned discussion, in the end I was right: I/O plays
> a bigger role there than function call overhead, right?

Well I think it's hard to separate out that cleanly. (I also haven't sat
down and done the profiling, so this is an educated guess.) Updating
from servers takes a while, of course, but when people complain about
Gnus being slow, I don't think they're complaining about hitting "g" and
having to wait a few seconds.

I think mostly they're complaining about the time it takes to open and
display a summary buffer. That's a combination of I/O time (requesting
enough header data from the server to build the summary lines) and
producing the lines themselves, which I think often *is* bound by
computation time: formatting the lines, maybe calculating scoring, and
building threads correctly. Shutting threading off or using a simpler
threading algorithm, for instance, gives a noticeable speedup.

I don't see what we can do about the server requests (Gnus already has
facilities for prefetching). Probably more can be done to pre-render and
cache the summary buffers, but Gnus already has quite a few
optimizations here (inlined byte-code, for example).

> So maybe “breaking the defuns into [parts]”, if done correctly, wouldn’t
> “make it even slower”?

Like I said, I haven't profiled, but I wouldn't guess this is a main
cause of slow-down. Really someone should just sit down with the
profiler and try to find the bottlenecks.

Eric

Re: inline

[Adam Sjøgren]

Eric writes:

> Like I said, I haven't profiled, but I wouldn't guess this is a main
> cause of slow-down. Really someone should just sit down with the
> profiler and try to find the bottlenecks.

Yes! I can't agree enough; profile, measure before, measure after.


  :-),

   Adam

-- 
 "I pragmatically turn my whims into principles!"             Adam Sjøgren
                                                         asjo@koldfront.dk

Re: inline

[Emanuel Berg]

Adam Sjøgren wrote:

> Yes! I can't agree enough; profile, measure
> before, measure after.

Do it yourself Adam :)

    What you can't measure,
    you can't control.
    -- Pierre Vernier

(Well, he could have said it, at least.)

-- 
underground experts united
http://user.it.uu.se/~embe8573