While most cpickle files are relatively small, kde is huge and syncing (mean: rewriting) file kde-base-eclass.cpickle after each write means that "Updating Portage cache" show 50% several times longer that any other number. Of course better that rewriting counter will be to speed up generating of cpickle files or at least kde-base-eclass.cpickle, for example by syncing less often.
Try this patch (run emerge metadata after applying). http://dev.gentoo.org/~ferringb/portage/2.0/3.0-cache-backport-experimental-7.patch Closing LATER.
Hey ! What is cache.cache_errors ? Hmmm ... don't you forgot to add something like copying some files to /usr/lib/portage/pym/cache ? I hope it's only think you forgot ...
Yes, it feels much faster and steadier. I'll try to make some benchmarks later to have real numbers.
(In reply to comment #2) > Hey ! What is cache.cache_errors ? > > Hmmm ... don't you forgot to add something like copying some files to > /usr/lib/portage/pym/cache ? I hope it's only think you forgot ... I see no errors, using this patch myself. I assume that anyone who tests this patch knows how and where to apply this. If not, then better don't mess with portage. ;)
You mean it's not supposed to be applied while emerging portage ?