Re: 28.0.50; Proposal: slightly more efficient package-quickstart.el

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Not so much, but it is not so much about noticable difference, more
> about not performing unnecessary computation.

But Emacs is more often limited by manpower than CPU, so the impact on
code complexity should not be discounted.

> As the loop progresses, for every dir N, the loop does N-1 path
> comparisons. These are unnecessary comparisons since when we know for
> sure that the string is not added yet. Trend in Emacs seems to go
> towards having more and more packages installed. This removes
> N(N-1)) comparisons.

I know.  But you have to get to a list of at least 2000 elements
before this N² starts making a noticable (0.2s) difference [tested on
an old 1GHz Cortex-A8.  ]

By the time the user has 2000 packages installed, there are several
other performance problems that will be more noticeable, I'm afraid.
E.g. the length of `load-path` itself will be a source of slowdown.

I know 200 packages is fairly common nowadays, so 1000 or more in not an
outlandish idea, and there are indeed performance issues that come up
when we have many packages, but I suspect that we'll need more thorough
changes to tackle this, and in any case it should be driven by concrete
measurements, otherwise we'll waste our time optimizing details that
don't actually matter.

>> Beside the hypothetical risk that the regexp matches an `add-to-list` to
>> an unrelated variable, I think this risks introducing real bugs for
>> packages which use (add-to-list 'load-path <subdir>) to add
>> *sub*directories.
> Yes, I was aware of it, but I am not sure how to write the regex, to
> avoid that risk.

I don't think you can avoid that problem by fixing the regexp, but
rather by `read`ing the sexp and looking at the directory it adds to
make sure it is indeed one of the ones you're adding "by hand".

Or maybe a better approach is to do something like what we do with
`Info-directory-list`, tho it might also be tricky to "get it right".

>> Of course, we can fix those problems, but unless there's a compelling
>> performance argument, I think it's a waste of time.
> It's quite simple to do,

It's not if you want to handle correctly the corner cases, as this email
discussion shows.

> I don't know, at least in theory :).

Maybe there's a theoretical gain.  But there's a very real practical
loss in time spent getting the code to work correctly and maintaining it
in the future.


        Stefan