James Antill (illiterat) wrote,

YUM resource usage, an accurate assessment

As a YUM developer it's hard not to notice the number of complaints/attacks on YUM about it being slow and/or using too much memory, the most common thing about almost all of these complaints though is how inaccurate they are. To be clear, YUM did used to take a lot more time than was required to do simple operations and there are very likely some more improvements that can be made for certain situations BUT yum is currently "not slow" at most normal operations for Fedora users and RHEL/CentOS users should be getting a much newer/faster variant than they currently have in the very near future.

The most common misleading piece of data is to directly compare YUM to APT, smart or Zypper. The most obvious problem is that the commands/interfaces do not directly map between applications, and so hard to compare. For instance, at the simplest level, "yum install" accepts package names, "provides" or filenames contained within a package all of which can have wildcards and/or some of epoch/version/release/arch. But the problem goes even deeper than that, as the core assumptions each application makes are very different and so hard to compare. For instance, yum will automatically update it's metadata for the configured repositories but smart and apt both require the user does this manually. Or that yum/rpm is assumed to be used in an environment that has dependencies which use a combination of package names, versioned PRCO (Provides, Requires, Conflicts and Obsoletes) and explicit file dependencies.

In short it's fair to say that each package management tool has a close relationship with the main distribution(s) it is developed for, if for no other reason than that's where the developers tend to come from but also in more than one instance in the last 6 months specific cases of how new YUM features would work were defined by Fedora and not just the YUM developers.

Which brings us to YUM resources usage within Fedora/etc. which, as I said initially, in older versions has been a real and valid complaint against YUM. However the situation has been much improved over the last year. The use cases for which current YUM can still be "significantly" slower than we'd like is vanishingly small. Obviously Fedora 7 and 8, as well as RHEL/CentOS 5 will be slower to pickup the speed enhancements that have been made since 3.2.8, however this is not a failing of YUM more a consequence of the longer release periods associated with those distributions.

As a final note I'd say that the biggest reason a lot of these recent complaints annoy me is not just that they are inaccurate but that they tend to grossly mislead the reader into thinking that "package management" is a solved problem and the biggest obstacle to solve is whether "install foo" takes 3 seconds or 6 seconds. In my opinion this could not be further from the truth, managing 2-6 machines is an ugly problem in all the current solutions and managing 100-10,000 is basically not done. Then there are things like the 10x10 problem, where we are only starting to see ideas like KOPERS which might help solve the problem (but will require changes in the way package management is assumed to work). And that's completely ignoring the problems that have had attempted solutions (that failed) multiple times, like "rollback" support.

Tags: benchmarks, performance, yum
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded  

  • 3 comments