Dimitrios Apostolou <jimis@xxxxxxx> writes:
> I'll post here because I just subscribed to that list and I can't
> reply to the thread.
Fair enough, I'll Cc this to both lists.
> I just tried your committed changes and indeed it makes a big
> difference. Thanks for incorporating these ideas. The average times I
> see for check-update are about the following:
>
> without-exclude with-exclude
> yum-original 26s 24s
It is interesting, that skipping the package creation was faster than
running the exclude operation.
> yum-james 15s 20s
> yum-jimis 12s 11s
>
> For excludes I used "-x '*p*'" which is probably an extreme case.
Yeh, it is extreme in the way that it hits a lot of packages but has
only a single matcher.
It'd also be interesting to see how much slower 3.2.23 is as that had
to load all the packages before it ran the exclude on them (I'm
assuming this is easy for you to test).
> I
> also included my version just out of curiosity. I attach the diff for
> the version I used, which includes small doc fixes and overrides
> properly the simplePkgList() method as you suggested.
*nods* ... it does undo all the recent changes too, which is a bit of
noise. You also combine changes to returnObsoletes() and
simplePkgList() ... and I'm _guessing_ that the returnObsoletes()
change doesn't do much.
I'm somewhat surprised by the time difference for without exclude
(I've attached a "micro optimization" patch, which might affect
that¹).
Maybe you'd lose that 20% advantage if your version was complete
(esp. when you account for things like versionlock), but it'd be
interesting to see where that 20% comes from.
I'm less surprised by the times for with exclude, as your test seems
very worst case to me (and likely where the biggest benefit would
come, by pushing excludes down to the SQL level).
But I think an even better solution there is if we can somehow cache
the result of all repos. post excludes, which would solve a number of
interesting cases including this ... although the pain smart goes
through to do that kind of thing is deterring.
Anyway, here's the quick micro opt. patch against yum-3_2_X HEAD.
diff --git a/yum/sqlitesack.py b/yum/sqlitesack.py
index 5b75cf5..7a2b700 100644
--- a/yum/sqlitesack.py
+++ b/yum/sqlitesack.py
@@ -585,6 +585,9 @@ class YumSqlitePackageSack(yumRepo.YumPackageSack):
self._delPackageRK(repo, pkgKey)
return True
+ if not self._pkgExcluder:
+ return False
+
data = {'n' : n.lower(), 'pkgtup' : (n, a, e, v, r), 'marked' : False}
e = e.lower()
v = v.lower()
¹ The patch shows a couple of tenths of second improvement, for me,
and so is probably worth it anyway. Also if I go to extreme lengths to
almost always skip the three tests before that I get less than another
tenth of a second improvement.
--
James Antill -- james@xxxxxxx
_______________________________________________
Yum mailing list
Yum@xxxxxxxxxxxxxxxxx
http://lists.baseurl.org/mailman/listinfo/yum
