Received Tue 02 Oct 2007 1:36am +1000 from Jeff King:
> Package: wajig
> Version: 2.0.37
> Severity: wishlist
>
> Running "wajig new" takes a very long time:
>
> $ time wajig new
> [... wajig new output, 5 packages ...]
> real 1m36.576s
> user 1m35.570s
> sys 0m0.652s
>
> I haven't profiled it closely, but I assume there is some bad
> algorithmic behavior. As a proof of concept, I created the following
> shell script that does the same thing much more quickly:
>
> -- >8 --
> #!/bin/sh
>
> OLD=$HOME/.debnew-packages
> NEW=$OLD.new
>
> set -e
>
> update() {
> test -e $OLD || touch $OLD
> apt-cache pkgnames | sort >$NEW
> }
>
> show() {
> echo '==> Added packages'
> comm -13 $OLD $NEW |
> xargs --no-run-if-empty apt-cache show |
> perl -ne '/^Package: (.*)/ and $package = $1;
> /^Description: (.*)/ and printf "%-24s %s\n", $package, $1;'
> echo '==> Removed packages'
> comm -23 $OLD $NEW
> }
>
> case "$1" in
> mark) mv $NEW $OLD ;;
> *) update; show | less -S ;;
> esac
>
> -- >8 --
>
> On the same dataset (and producing the same results, albeit with
> slightly different formatting):
>
> $ time debnew
> real 0m2.390s
> user 0m2.048s
> sys 0m0.348s
>
> Is there any interest in trying to integrate this into wajig? It might
> also be possible to simply fix the performance issue currently in wajig,
> but I don't have any experience with profiling python, so I'm not even
> sure which part of the code is the culprit.
Thanks for the bug report.
I've not been able to repeat. For example:
$ time wajig new
[27 packages]
real 0m0.996s
user 0m0.784s
sys 0m0.336s
$
Wajig is essentially doing the same as you suggest. I save the list of
packages in ~/.wajig/Available and ~/.wajig/Available.prv. I extract
(in python though) those in one and not in the other. Then list the
results, getting the descriptions from dpkg and print them.
Do you repeatably get the 1 minute execution?
Regards,
Graham
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
