Ciaran McCreesh wrote:
On Wed, 25 Feb 2009 09:33:44 +0100
Alexis Ballier <[email protected]> wrote:
That sounds like an implementation detail that you could solve by
using something else than a flat file database for metadata if
open()/read() calls are the slow part.
Metadata's shipped with the tree. It's a PMS detail.
If we didn't care about package manager performance, we wouldn't be
shipping metadata with the tree at all...
I would be very surprised if that "2 times" factor happens to be
true, because finding a string in a file is an order of magnitude
simpler than sourcing said file with bash. Moreover this doesn't
take into account disk and os cache.
No no no. *Opening* the file is the slow part, not searching. The
file wouldn't otherwise be opened at all.
Thus the only drawback is when you open a file, see there that you
can't handle the eapi, then close it and open an older one.
Uh. No. The drawback is that you're opening around ten thousand files
that would otherwise not be opened. That's a huge cost.
Huge cost...
emerge -uDp world (cold os cache)
real 1m10.353s
user 0m17.077s
sys 0m0.440s
with eapitool getting the eapi before sourcing.
real 1m10.636s
user 0m16.941s
sys 0m0.368s
cold cache, no metadata available
real 6m23.106s
user 3m32.141s
sys 1m50.855s
with eapitool
real 6m26.564s
user 3m31.853s
sys 1m50.511s
I'd rather see more people backing their ideas with numbers...
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
