[pacman-dev] more efficient use of db_cache needed
Hi! It's common practise that you load pkgcache with INFRQ_DEPENDS or similar which is slow, because you must read the whole db directory. Instead it would be more optimal, if you'd load db_cache with INFRQ_NONE almost always (in case of thransactions where only few packages are affected), because that is very fast (name and version are computed from the directory name, so you need to read only the root directory of the repo). And if you find the required package by name, you can read the required info. So first _alpm_db_scan with INFRQ_NONE then _alpm_db_read Bye, Nagy Gabor
On 2/28/07, Nagy Gabor <ngaba@petra.hos.u-szeged.hu> wrote:
Hi! It's common practise that you load pkgcache with INFRQ_DEPENDS or similar which is slow, because you must read the whole db directory. Instead it would be more optimal, if you'd load db_cache with INFRQ_NONE almost always (in case of thransactions where only few packages are affected), because that is very fast (name and version are computed from the directory name, so you need to read only the root directory of the repo). And if you find the required package by name, you can read the required info. So first _alpm_db_scan with INFRQ_NONE then _alpm_db_read
We already went over this before. In the future, all package access will be done with the accessor functions, loading the individual files on demand.
Na Wed, Feb 28, 2007 at 01:55:34PM -0600, Aaron Griffin <aaronmgriffin@gmail.com> pisal(a):
We already went over this before. In the future, all package access will be done with the accessor functions, loading the individual files on demand.
you may want to have a look at pacman-g2, there this is already done VMiklos -- developer of Frugalware Linux - http://frugalware.org
Na Wed, Feb 28, 2007 at 01:55:34PM -0600, Aaron Griffin <aaronmgriffin@gmail.com> pisal(a):
We already went over this before. In the future, all package access will be done with the accessor functions, loading the individual files on demand.
you may want to have a look at pacman-g2, there this is already done
VMiklos
Hi! Yes, but I hope, this is the first step only. Because in the current state of the db backend this is totally useless, because you _must_ read the whole local repo with INFRQ_DEPENDS in almost all cases (in usual cases), and the whole sync repos with many cases. That's why I don't stop saying: .providers, .brokendeps, .groups are musthave. (Or any of your solutions to stop this terrible practice.) Nagy Gabor
Na Thu, Mar 01, 2007 at 01:12:49PM +0100, Nagy Gabor <ngaba@petra.hos.u-szeged.hu> pisal(a):
Because in the current state of the db backend this is totally useless
nope see http://frugalware.org/pipermail/frugalware-devel/2007-February/003092.html thanks, VMiklos -- developer of Frugalware Linux - http://frugalware.org
On 3/1/07, VMiklos <vmiklos@frugalware.org> wrote:
Na Thu, Mar 01, 2007 at 01:12:49PM +0100, Nagy Gabor <ngaba@petra.hos.u-szeged.hu> pisal(a):
Because in the current state of the db backend this is totally useless
nope
see http://frugalware.org/pipermail/frugalware-devel/2007-February/003092.html
I agree 100%. The current backend isn't *totally useless*. Sure it has it's share of problems, but it can be improved without the use of massive amounts of cache files as suggested above. The only potential cache I thought of using, would be a cache of names and descriptions for each repo... call it a "search cache". However, that'd only speed up searching. The real solution is to change / tweak the actual implementation on disk. Perhaps I'll take the nod from VMiklos and actually change all the package functions tonight, as it appears it's a much larger improvement (and thus much more valuable) than I expected.
Na Thu, Mar 01, 2007 at 01:12:49PM +0100, Nagy Gabor <ngaba@petra.hos.u-szeged.hu> pisal(a):
Because in the current state of the db backend this is totally useless
nope
see http://frugalware.org/pipermail/frugalware-devel/2007-February/003092.html
thanks, VMiklos
Oh yes, you are right. I remember now. But I said 'in almost all cases too' :-). Anyway, we are saying the same: these are the rare cases (now!) where is not needed to read the whole repo (earlier you did it); that's the reason for the big speedup. I want to reach this for almost all operations... Bye, Nagy Gabor
participants (3)
-
Aaron Griffin
-
Nagy Gabor
-
VMiklos