bug#70108: 29.1.90; `defalias' and `current-load-list'

[Mickey Petersen <mickey@masteringemacs.org>]

Hi Stefan,


Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> This obviously goes into the C core where a bunch of stuff takes
>>> place. One of variables that gets updated (somehow) is
>>> `current-load-list'. Curiously, it ends up with duplicate entries. I'm
>>> presuming there is a good reason for this.
>
> Duplicate entries sounds like a bug (unless there are two calls to
> `defalias` for the same function name within the same file).
> Do you have a reproducible recipe that shows this?
>

That is exactly the scenario. There's a setup function that gets
called, which in turn sets up the defaliases. Each test would then end
up calling this setup function, which would result in the same file
foo.el calling defalias multiple times for things it has already
defined.

Still, I find it a bit odd that it's *that* slow. We're talking
hundreds, not millions, of entries.

As I mentioned earlier, I do not think it's a bug, but it caught me
out, so I figured I'd at least ask.

>>> This variable can easily get overrun with identical entries if the
>>> inattentive programmer does not check if it is already bound.
>
> Hmmm... I'm beginning to wonder: do your `defalias` happen while loading
> a file, or do they happen more "dynamically"?
>

The file is loaded once as part of the batch emacs process to run the
tests, and unless there's some ert shenanigans I'm not familiar with,
I do not think so.

>>> I have not narrowed down exactly *why* my ERT suite, when beset by 600
>>> tests to run in one go, causes the slowdown. What I'm guessing from
>>> how each successive tests slows down, that there is some sort of
>>> non-linear searching going on here, and either `load' (and friends) or
>>> the mere fact that putting more defaliases into the system causes this
>>> slowdown to occur.
>
> The most common culprit is "N linear searches in an N-long list".
>         Stefan