Re: Naming, and Gnus functions length [

[Garreau, Alexandre]

On 2018-10-08 at 17:43, Emanuel Berg wrote:
> Garreau, Alexandre 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?
>>
>> Maybe Gnus functions length are just a question of style. I guess
>> their developers are experienced enough to know how to properly use
>> manual inlining. And anyway, as, as you pointed it, Gnus can already
>> be sometimes quite slow, it’s probably more because of I/O than
>> function call overhead, so this later must be neglictible in
>> comparison. So Gnus functions length is probably unrelated.
>
> I once said to the Gnus developers, why don't you break down those
> age-long functions, to make it much easier to read and maintain the
> code?
>
> They said Gnus is slow, Elisp is slow, and breaking the defuns up into
> neat modules would make it even slower.

Seriously? is Gnus so complex (algorithmically at run-time I mean)?
damn, I wouldn’t have figured out…  Then indeed maybe it could… as these
“neat modules” would be only used by Gnus and not all the way around…
but yet: keeping the dynamic behavior (which must be wanted since no
defsubst/define-inline is already used to fix this), while having the
neat modules, if they’re ubiquitous enough, might mean recompiling a big
part of Gnus at each changed function.  So in the thesis of an
automatically-optimizing compiler, maybe the compiler wouldn’t inline
that much…