autocomplete on abra recipe upgrade
is slow
#567
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Not quite a "bug" but it does cause a little friction.
Autocomplete on recipe names is much slower than on app names. Probably because app autocomplete is based on listing files but recipe autocomplete is based on parsing JSON. Maybe there's nothing we can do but if it's possible to optimise it'd be awesome
CC @trav
Yeh I would love to speed this up also, I routinely get frozen waiting for this...
I think it might be doing some network activity in there somewhere....
Definitely something to improve!
When autocompleting recipe names, it first ensures the recipe catalogue is up to date. This makes it slower. We have the following options:
abra recipe upgrade <tab><tab>
It only ensures onceThanks @p4u1 ! 🙏
#3 seems good, but maybe the most complex to implement – and it might be hard to avoid it being "first autocomplete invocation per shell".
#1 seems easiest but most fragile.
I am leaning towards #2 – but am I correct that we don't have a specific command to sync the recipe catalogue?
option 3 is actually quite easy to implement. This would also be the safest option, but it would still be slow on the first each time you run abra recipe upgrade
also you are correct that there is no command to sync the recipe catalogue. With option two would then need that i guess..
OK! Out of interest, how are you thinking abra would know whether to refresh the catalogue?
Thanks for thinking this one through! It might make sense to do a
abra catalogue sync
and then make all catalogue operations local only? Then if you're missing something you expect to be there, you run a sync?This is all the places that
recipe.ReadRecipeCatalogue()
is called, so it's quite significant and contributes to slowing things down. Also, we tried to get around this before by adding atrue
/false
argument if it should only do an offline operation.One optimisation could be to check if
go-git
has any way to remotely query the last modified value of the catalogue repository? Then you would know potentially faster if you need to actually do a full pull or not. I'm not sure this is provided and if it would offer a better experience in the "need to pull" case.Not sure on this one!
My proposal is option 2. I don't understand how option 3 would know how to only do it once and I am not much of a fan of doing some sort of bookkeeping to remember this. Please do let us know though if there is some way to manage it. Then, I would go for:
abra catalogue sync
to update catalogueThis way, it's less automatic but should be faster for the day-to-day use. If you can't find it in the auto-complete, you know you should
abra catalogue sync
. And the implementation should also make sure it pulls in the local recipe listing too (which I think it does).RFC: #604