#13 faster compare patch

[David Everly]

This patch seems to allow faster pkgutil -c/-C operation by skipping some compare logic when the pkg is not in the catalog. Since I'm not aware of the purpose of listing items that are not in the catalog, I could have easily broken something with this patch, so please let me know what logic I may have missed if this is true). Thanks!

--- /opt/csw/bin/pkgutil Thu Dec 10 19:53:29 2009
+++ pkgutil Mon Dec 28 19:35:15 2009
@@ -127,8 +127,9 @@
}
foreach $pkg (@cswpkgs) {
($pkg) = ($pkg =~ /\s+?(\S+?)\s/);

• $local_ver = check_pkg($pkg,0);
  $remote_ver = parse_catalog($pkg,1);
• next if ($remote_ver eq "not in catalog");
• $local_ver = check_pkg($pkg,0);
  $remote_ver = "SAME" if ($local_ver eq $remote_ver);
  if ($mode == 1) {
  push(@retlist,$pkg) if ($remote_ver ne "SAME" && $remote_ver ne "not in catalog");

[David Everly]

I should have reported my own testing, the only differences appeared to be in:

compare(0) / pkgutil -c
compare(3) / pkgutil -C

And in both these cases the only difference was a shorter list (all the 'not in catalog' listings were present when using the original pkgutil and not present when using the patched pkgutil).

This patch seems more correct in the case of 'pkgutil -C'.

I suppose it could be argued that 'pkgutil -c' should show all locally installed pkg that are not in catalog (but then why not also show all catalog pkg that are not installed).

And so if one wants to retain the existing behavior of 'pkgutil -c' then the patch could be altered from:

next if ($remote_ver eq "not in catalog");

to:

next if ($remote_ver eq "not in catalog" && $mode == 0);

[David Everly]

Bah, my reversal of logic... I should have said...

next if ($remote_ver eq "not in catalog" && $mode != 0);

...to keep the existing 'pkgutil -c' behavior.

[David Everly]

faster compare patch (earlier patch pasted into comments was corrupted)

[Peter Bonivart]

This saves a lot of time for comparing locally installed packages that are not in the catalog. However, those should be very few, especially for a normal user. On one of my test systems I have around 100 CSW packages installed, only three of those are test packages not in the catalog so the time saving would only occur on 3% of the whole set in my case.

I bet 99% of the time a compare takes is spent waiting for the fork to /bin/pkgparam to return a result. There's not much I can do to speed that up.

What I'm thinking about is making the pattern matching feature of compare faster. Now it's pretty stupid just filtering the output of a full compare thus taking the same time even if only one package matches. I could skip comparing packages that don't match the pattern. That would make it much faster.