You are not logged in.
A negative response from the sync database takes way too long if the sync database is not in the file cache:
# dropcaches; time pacman -S 345bn34jfnkwejn3i4
pakiet 345bn34jfnkwejn3i4 nie został znaleziony, szukanie grupy...
błąd: '345bn34jfnkwejn3i4': nie znaleziono w bazie danych synchronizacji
real 1m6.239s
user 0m0.340s
sys 0m1.327sOne minute and six seconds! I realize that fetching data from disk is slow, but libalpm still does it about ten times slower than it can be done:
# dropcaches; time cat `find /var/lib/pacman/sync -type f` > /dev/null
real 0m6.497s
user 0m0.353s
sys 0m1.110sIn fact if you prefetch the database just before invoking pacman, the actual processing by pacman takes about one second. Here is a measurement of prefetch and pacman time combined:
# dropcaches; time bash -c "cat \`find /var/lib/pacman/sync -type f\` > /dev/null; pacman -S j3h4bfqernbqemrf"
pakiet j3h4bfqernbqemrf nie został znaleziony, szukanie grupy...
błąd: 'j3h4bfqernbqemrf': nie znaleziono w bazie danych synchronizacji
real 0m7.913s
user 0m0.583s
sys 0m1.300sAbout 8s vs about 60s is some improvement!
Offline
First time it'll take a bit, but the second query will be fast.
Please, use LC_MESSAGES=C (run 'LC_MESSAGES=C pacman -S blah') before posting because most of us here don't speak Polish.
Edit: on my system 'find' runs for about half a minute, so the difference is less significant.
Last edited by karol (2009-12-11 18:12:03)
Offline
First time it'll take a bit, but the second query will be fast.
You didn't read carefully enough. Yes, "first time" is slow, but since it is "first time" most of the time when you want to use pacman, the "first time" performance is the one that needs to be improved. I ensure the "first time" condition with the dropcaches command before running the measurement.
Edit: on my system 'find' runs for about half a minute, so the difference is less significant.
It's not just find, it's find and cat each found file to /dev/null so that it gets cached. What are your specs and filesystem mount options?
Offline
Do you mean sth like that:
http://bugs.archlinux.org/task/8586
http://bbs.archlinux.org/viewtopic.php?id=20385
http://bbs.archlinux.org/viewtopic.php?id=22600
http://bbs.archlinux.org/viewtopic.php?id=45077
Edit: if you want to find out if the particular package is in the db you may as well use locate - I doubt that find can beat it in terms of speed :-)
My disk is old and slow, but in most cases it still takes more time to download sth and install than to search the db (yeah, my internet connection is slow too).
Last edited by karol (2009-12-11 19:37:16)
Offline
Looking into these.
Edit: if you want to find out if the particular package is in the db you may as well use locate - I doubt that find can beat it in terms of speed :-)
There are problems with this method (think %PROVIDES%) but the point is that I don't just want to fin out if the particular package is in the db. Queries like -Ss, -Si, -Qs, -Qi, -Qo etc. all involve full database scan.
BUT BUT BUT perhaps the whole concern is invalid: tadaaaa, I re-ran the measurements today and the behavior is reversed: pacman -S fyvaprol is fast to report a negative (8s) while find /var/lib/pacman/sync -type f is slow (44s). Something really weird is going on my system. I'll re-run the tests tomorrow and the day after tomorrow, and if the slowness won't come back, I will mark the topic [solved].
Last edited by Rulatir (2009-12-12 10:32:12)
Offline
> BUT BUT BUT perhaps the whole concern is invalid
That's what I was trying to tell you. I rebooted my machine after each test to be extra safe and yes, the first query is slow but fast enough for me. I use that time to stretch my legs, make coffee etc.
Offline
> BUT BUT BUT perhaps the whole concern is invalid
That's what I was trying to tell you. I rebooted my machine after each test to be extra safe and yes, the first query is slow but fast enough for me. I use that time to stretch my legs, make coffee etc.
Sadly you still don't understand.
Note well the very first command in each test:
# dropcaches
This command causes invalidation of all file caches. It ensures the "first query" condition. Since this is the condition I am interested in, I always prepend dropcaches before the timed test. The change of behavior I reported in the "BUT BUT BUT" part is a difference between a "first query" on one day and another "first query" on another day. The "first query is slow, but it loads the DB into the file cache and the subsequent queries are fast" phenomenon has absolutely nothing to do with this because I purge the file cache with the dropcaches command before each test.
Offline