Hi!
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)
Regards,
Matthias
2012/6/4 Michael Schroeder
On Mon, Jun 04, 2012 at 01:36:51PM +0200, Matthias Klumpp wrote:
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 display it. 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 too. 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).
Cheers, Michael.
-- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org