perf(runtime): hardware accelerated "packadd opt_package"

fixes #37586

when doing `packadd mypackage` up to two exact paths are added
to &rtp. Instead of recalculating runtime_search_path from scratch,
we can "just" splice these two paths in

This is simple in theory, but get complicated in practice as
"after" dirs do exist and need some wrangling.

Echasnovski did some benchmarking, to show that this reduces overhead
of a init.lua configuration style where separate `packadd!` calls are
used spread out during the config. In addition, "batched" addition
(either using "start" packages or packadd! a lot of opt packages at
once) does not regress.

A theoretical simplification could be to NEVER explicitly add "after"
dirs to &rtp, but implicitly add all existing "after" dirs in reverse
order when calculating the effective run time path. This might be tricky
to do without breaking 12 tpope plugins again tho.

We might also instead consider solutions where &rtp remains fully expanded but no longer is the main source of truth. But this is all post 0.12 work. This PR is an alright stopgap to make 0.12 fully support intended use cases of vim.pack.add() .

0 files changed, 0 insertions, 0 deletions