On Tue, Nov 17, 2009 at 12:44 AM, Laszlo Papp <djszapi2@gmail.com> wrote:
Signed-off-by: Laszlo Papp <djszapi@archlinux.us> --- HACKING | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/HACKING b/HACKING index 537d9a3..63ccf1e 100644 --- a/HACKING +++ b/HACKING @@ -146,6 +146,14 @@ For example, to run valgrind: ./src/pacman/pacman valgrind --leak-check=full -- src/pacman/.libs/lt-pacman -Syu
+How should I make benchmarks? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +pacman spends most time with reading and writing the database. because of this, +it's important to drop caches before doing a benchmark. here is how to do so: + +# echo 3 > /proc/sys/vm/drop_caches +
This is a completely retarded statement. 1) pacman spends most time with reading and writing the database WRONG This depends whether it is cached or not. In a real world situation, you will have only one uncached run of pacman (the first one) compared to many cached. It also depends on the operation. If you are going to download/install/remove a lot of (or big) packages, it's likely completely wrong. 2) because of this, t's important to drop caches before doing a benchmark WRONG This depends on WTF you are benchmarking in the first place. If you want to see the effect of your patch on the database reading/writing, you probably want to drop caches. If you want to see the effect on the rest, you probably do not want to drop caches. This tip to drop caches can sometimes be very useful, so it might be worth mentioning in the HACKING file. And pacman database is indeed quite inefficient (the first run on my laptop is painfully slow). But can you please *think* about what you are writing twice (or more) before sending it ? And common sense helps too, did you ever think about getting some ? I enjoy this list a lot and communicating with everyone else here. I don't know how you manage to piss me off with every mail you send.