Hola. So... short version, for those who weren't aware, cache subsystem got gutted and rewrote in >=2.1 base code.
Couple of reasons why the old design needed to be pitched 1) Lots of forced stat calls for no good reason. 2) designed around per category, which doesn't fly when you're doing a remote cache- pooling being *required* for rdbms for a single repository cache sucks. 3) Two seperate caches per repository effectively; eclass_cache (which is global), and repository cache. So... those are the main 3. Cache rewrite that's in 2.1, and 3.x (latter being saner since it's actively worked on) I've backported to stable, and attached to this email. It's... kind of large, but there's a couple of good reasons for it. The original cache cleansing code is included, throwing out emerge's reimplementation of it (this one is a bit more extensible)- beyond that, eclass_cache got ripped out of portage.py and into it's own module. Portage.py modifications are pretty minimal also. I'd be *very* interested in timing runs for with, vs without- the cache rewrite lacks a lastX cache that was used in stable's cache to cover up performance issues. Probably will need to throw in a wrapper to stable re-adding it, due to the fact stable's calling patterns to the cache are bad (instead of making a single request for all keys needed, makes N calls resulting in N io actions rather then 1), but I'd like to get stats backing that up before adding a bandaid back in. Either way, test, feeding stats back, etc, would be appreciated ;) Thanks, ~harring
3.0-cache-backport.patch.bz2
Description: Binary data
pgpSXbMdeHtPM.pgp
Description: PGP signature
