Log in

Lies, damn lies, and benchmarks - James Antill

Jul. 31st, 2009

02:47 pm - Lies, damn lies, and benchmarks

Previous Entry Share Next Entry


[User Picture]
Date:August 2nd, 2009 04:36 am (UTC)

Speed bugs are just bugs...


I'd advise finding speed bugs the same way I'd advise trying to find other bugs ... the most obvious step is to contact a yum developer (and def. not post to the closest mailing list :).

For instance when we recently pushed a regression which made "cost" go from seconds to minutes, a bunch of people spotted it (one even saying it worked fine if he commented out a particular line of code) and we eventually found the underlying problem (but it took me hours to work out what the problem was).

But I'm pretty sure a normal user wouldn't have been helped by detailed instructions on how to isolate parts of commands.

When I listed the "10 things the update command does" I didn't mean I thought it would be useful to time each of them, quite the opposite ... I meant it more that it was pretty suspicious to compare some of the operation, because a normal user will often end up doing all of the operation. Specifically if the rpmdb and repos. aren't in core, doing the IO to read hat data can easily dwarf the depsolve time and it's very rare for a user to not confirm the transaction (and again, the IO there will often be the longest part of the operation, by far). So even a 75% difference in depsolving can easily be only 1% of the update operation.

(Reply) (Parent) (Thread)