Your suggestions still don't solve the issue that I can't run multiple
transactions at the same time - some backends don't support that also.
So I will have to run super-big transactions while starting the SC and
cache all results, which is slow.
Just for understanding, a "transaction" is any action which performs
any task on the package database using a PackageKit backend, for
example InstallPackages(), RemovePackages(), GetDetails(), Resolve()
... You can run these actions on multiple packages, but that is slow.
Just running it for one package as soon as we need the results is
better but still slow and if we're doing InstallPackages(), we can't
run GetDetails() at the same time.
Nearly all package-manager backends aren't threadsafe, so
parallelizing that could cause unexpected behavior.
To see how slow these actions are, you can just try an older SC
version or maybe run "pkcon get-packages", but without having the
caches enabled. (PackageKit already cached some of these data, to
enable fast filtering in frontends)
2012/6/4 Michael Schroeder <mls(a)suse.de>de>:
On Mon, Jun 04, 2012 at 01:36:51PM +0200, Matthias
The database is in PK and therefore generic, it
can be used by every
other tool too. The Xapian database you mentioned is the AppStream DB
with application data and the packages in which the application is, it
does not contain other data. (well, not entirely true, but that's the
most important part)
Now the SC needs to query certain information from PK, e.g. if a
package is already installed or the description of a package to
Problem here is that you can't run thousands of Resolve() calls on
PackageKit, as this is very slow and there's no chance to optimize it.
Why not? How about adding a "ResolveMultiple()" or something like that?
Also, all data has to go through DBus, which
slows down the process
Solution was to first optimize these calls, which is done already.
Unfortunately, if a transaction is running you also can't spawn
another one, so e.g. while you're installing Foo you can't view the
details page for Bar.
I don't see why you need to run a transaction for Resolve().
(It's probably also pretty PK-backend specific, I guess)
We now use the SQL cache to query this
information async and very
fast, without DBus.
So SC opens the PK sqlite database? That sounds pretty awful. Even
if there's a database it would be much saner to go through dbus
for the access (and use something like ResolveMultiple).
Michael Schroeder mls(a)suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org