seth vidal wrote:
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?
We'd need to do the same search in all three- - RPMDBPackageSack, the
pkgSack (SqliteSack) and the localSack - and after that do the pkgtup
lookup. Sound a bit like overkill.
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.
Yeah, I probably should choose my words with a bit more care...
You understood quite right: a lists/sets of that still needs to be checked.
Florian
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
