[pacman-dev] Feature request: Show exact matches first
Allan McRae
allan at archlinux.org
Wed Oct 19 23:35:10 EDT 2011
On 20/10/11 05:45, Dan McGee wrote:
> On Wed, Oct 19, 2011 at 2:37 PM, Markus Jochim<ich at markusjochim.de> wrote:
>> Dear developers,
>>
>> I'd like to request a feature. When I search for some package, let's say
>> openconnect:
>>
>> $ pacman -Ss openconnect (or -Qs)
>>
>> it takes quite a while until I get any results on my netbook (Atom N450
>> cpu). Maybe this could be sped up by showing exact matches right away. I've
>> had this situation quite some times now and it can be a real pain in the ass
>> to wait for 10 seconds (this may vary of course) when I simply want to know
>> whether I have a particular package installed.
>
> What is the *problem* you have here? Printing exact results first
> won't make it faster, so this is not a solution to the problem you
> originally stated- " it takes quite a while until I get any results on
> my netbook".
>
> -Ss should not be slow these days; the second and later runs take no
> more than 0.8 seconds on my Celeron M 900 Mhz machine; the first run
> likely takes no more than 2 seconds.
>
> -Qs could still be slow, but without some actual numbers, I don't even
> know what ballpark we're in here. `time pacman -Qs wontfindme` output
> would be nice here.
>
> Either use a closed ^regex$ as Karol stated if you want exact matches,
> or give us some timings of the runs of each command so we can see
> whats up and fix your problem as stated.
>
> -Dan
I agree that looking for a package with that exact name first will not
speed up an -Ss operation as the database read is all or none (and is
fast anyway). But maybe looking for a package with the exact name of
the search term first when doing a -Qs would be an OK thing to do?
Also, printing the exact match at the top of the search results may just
be a "good thing"...
Of course, what I really want to do is move the local DB to being fewer
files (I vote tar-based like the sync dbs...) and disk IO speed will not
be an issue.
Allan
More information about the pacman-dev
mailing list