On Wed, 25 Feb 2009 09:33:44 +0100
Alexis Ballier <aballier@g.o> 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.

-- 
Ciaran McCreesh