On Tue, 2005-04-05 at 21:20 +0200, Kyrre Ness Sjobak wrote: > tir, 05.04.2005 kl. 17.35 skrev seth vidal: > > > Is that worth adding yet another XML Parser package to the distribution > > > used by a single tool ? Is there a compatibility layer to still use > > > libxml2 ? > > > If I remember correctly, the performance problem wasn't libxml2 itself > > > but the specific usage within yum, i.e. collecting the data, libxml2 by > > > itself is parsing the megabyte sized file in less than a tenth of a second. > > > I'm surprized the solution ends up going to use a python specific library > > > instead of trying to find why the interface between libxml2 and yum generated > > > that problem. I don't remember you saying you would switch library as a result. > > > > well what happened was this: > > Icon was working on repoview and decided to try out CelementTree b/c he > > was using kid anyway and it used it. After some preliminary tests it > > showed up as significantly faster parsing the metadata. For > > primary.xml.gz the times went from 21s for 1800ish pkgs to 7s. Then when > > he switched it to use iterparse() the memory footprint dropped below 10M > > for the whole parse. > > > wow. That's just... amazing! > > Anyway: How large are the package in question? After all, yum is a > pretty "core" package. It's not some obscure fringe thingy. So adding > *one* package to support it can't be all that bad? > > After all, didn't OOo (another non-fringe package) pretty much cause > Java to be included? No, OOo only requires gcc-java and libgcj, nothing else. Eclipse was the big thing that pulls in all the real java support libraries. Dan
