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
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
