[Yum-devel] [RFC] TransactionInfo vs DepCheck

[seth vidal]

On Mon, 2007-08-06 at 13:52 +0200, Florian Festi wrote:
> Hi!
> 
> I've done some profiling runs to find quadratic behavior / places for 
> further optimization. It turned out that TransactionData (Why doesn't the 
> class name match the module name, btw?) .matchNaevr() uses up 25% of the 
> time of the "install [a-k]*" test case (large transaction with lots of 
> depsolving).
> I'd suggest to reorganize .pkgdict to {name -> [txmbrs]} and rename it to 
> ._pkgdict. This would make getting the txmbr of the given package slightly 
> more expensive but lets us getting rid of the linear runtime of .matchNaevr().

How would doing name->txmbrs compare with implementing
RPMDBPackageSack._search() in TransactionData?



> Second thing I'd like to do is killing the DepCheck class. I already argued 
> why I don't think the .check*() results should go there. So what's left in 
> there is are already_seen dicts. I'd like to move them to the 
> transactioninfo and to change them to one or may be two (install/remove) 
> positive list of what still needs checking. That would have the advantage 
> that we can add pkgs that are not part of the transaction. This could for 
> example be used to fix up broken installations (as --checkinstalled or as an 
> external tool). Having positive lists has also the advantage that these 
> lists don't keep growing which might be better for interactive users of the 
> depsolver like pirut.

I'm not sure I understand what you mean when you say 'positive list'. Do
you mean a list of things we need to check, as opposed to a list of
things we've already checked? That's what it seems like from what you've
described - but I just wanted to make sure you're not using 'positive
list' as a type of jargon.

-sv