Re: inline

[Eric Abrahamsen <eric@ericabrahamsen.net>]

"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