On Sat, 2006-12-16 at 17:35 +0200, Panu Matilainen wrote: > > > > -bash-3.1# time yum --disablerepo='*' --enablerepo='extras' list > > available >> /dev/null > ^^^^^^^^^^^^ > > > looks like it is less important on the olpc machine. given the numbers. > > It shaves a little less than a second. Keep in mind in that run of 1m38s > > it is only parsing primary.xml.gz for extras. > > That's because you're redirecting output of both to /dev/null. Time it > without that redirection like it was in my examples.
Do you seriously think it's going to shave off massive amounts of time to suddenly make the processing time USABLE if I don't redirect it to /dev/null? So I did the tests w/o /dev/null. It shaved off 7 seconds out of 4m35s for the makecache run. so it dropped to 4m28s This feels like deckchair shuffling. So let's step away from the deckchair shuffling and do a run of 'yum list available' w/o any special options or anything. This is a command that I think someone would commonly run: This system has 8 repos enabled: core 2242 pkgs olpc_devel_kernel_repo 15 pkg updates 1098 pkgs olpc_content 1 pkg olpc_development 36 pkgs extras 4984 pkgs olpc-csound 1 pkg olpc-etoys 15 pkgs here is the results: real 3m46.294s user 2m35.380s sys 0m11.020s now, I'll run it again w/ the info cached so it doesn't have to do the xml parsing: real 1m13.360s user 1m6.730s sys 0m2.030s It's still a lot of time at 1m13s so there's room for improvement in areas outside of the metadata parsing, too. But think about this in terms of user experience. Sit still for 2m30s and do nothing, except count the time. It'll drive you bonkers, quickly. -sv _______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
