Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#10379 - search speed is slow at first time

Attached to Project: Pacman
Opened by Daniel YC Lin (dlin) - Friday, 09 May 2008, 02:41 GMT
Last edited by Dan McGee (toofishes) - Saturday, 10 May 2008, 16:50 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To No-one
Architecture All
Severity Very Low
Priority Normal
Reported Version 3.1.3
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info:

I do command 'pacman -Ss xxx', when the first time, it is very slow(about 5 second).
But second time, it complete in 0.58 second.

I don't know is that my system's problem, or pacman's natural.
As I remember, the older version pacman seems haven't that problem.

My environment is: colinux(256M RAM) + archlinux + reiserfs
pacman 3.1.4
Root : /
Conf File : /etc/pacman.conf
DB Path : /var/lib/pacman/
Cache Dirs: /var/cache/pacman/pkg/
Lock File : /var/lib/pacman/db.lck
Log File : /var/log/pacman.log
Targets : None

Steps to Reproduce:
time pacman -Ss xxx
This task depends upon

Closed by  Dan McGee (toofishes)
Saturday, 10 May 2008, 16:50 GMT
Reason for closing:  Won't fix
Additional comments about closing:  This is due to the way the pacman DB works. It might get better in the future but we can't really do anything about it and there is a feature request open ( FS#8586  ) dealing with this.
Comment by Dan McGee (toofishes) - Friday, 09 May 2008, 03:08 GMT
This isn't a bug...pacman has to load its database, and it just happens that on subsequent runs the kernel has cached your database (/var/lib/pacman/sync/*) in memory so it doesn't need to go to the disk. It has always been the case- I'm not sure what you saw in the past that makes you think otherwise.

In the future, we would like to address this by reading directly from tar.gz archives rather than blowing up the database on the filesystem, but until then, there is nothing we can do.

Loading...