Speeding up the cache - Portage on the move towards 3.0

fei

What is the cache, why do I need it, and what's this metadata transferring thing?

The cache is metadata saved from ebuilds; without the cache, access would be about 400x slower for every ebuild lookup. The metadata transfer is as it sounds; the system's local cache is updated with pregenerated cache entries distributed via rsync, so that the user's machine doesn't have to regenerate portions of the cache itself.

Why is it slow?

The way stable's cache subsystem scales isn't exactly efficient; ebuilds using eclasses (which must be tracked) scales horribly, and rears its head in particular during metadata transfers.

What is being done to make it not suck?

A cache rewrite, which is in use in the non-stable branches already, has been backported to 2.0. Example statistics of the improvement are available via a discussion thread. Rough runtime reduction for a Pentium at 233MHz is 35% normally, with reduction of worst case runtime by 65%.

Nifty. Downsides?

Alternative cache backends need to be rewritten to work with the new design. Tools that access the on disk cache directly (eix) will need to be updated. This is still being tested.

When will it be available in portage?

2.0.54 is targeted, if it's not clean enough, .55 - in other words, as soon as we know it's bug free.

Is a patch available now?

Yes, http://dev.gentoo.org/~ferringb/ ... xperimental-7.patch is the relevant patch.

As per the norm, it's not supported yet; bugs, feedback etc. is welcome, but using it means you're taking the responsibility of patching your package manager -- a critical piece of a gentoo system. If it breaks, you're stuck cleaning up the pieces.

Warning: Adding it into the Portage ebuild for local use requires more than just a src_unpack addition -- src_install needs adjustment also.

druggo

大哥，能不能翻译一下啊，小弟英文不济……