2

I would have thought that pgrep would be much faster than ps -ef yet the contrary is true - pgrep takes about 4x longer. But only on my laptop e.g.:

$ time { ps -ef |grep foobar; }
real    0m0.027s
user    0m0.009s
sys 0m0.023s

Compare with:

$ time pgrep foobar
real    0m0.215s
user    0m0.189s
sys 0m0.021s

... the times above are representative of a typical run.

Context:

This is on an Intel i7 laptop running linux kernel 5.6.19-200.fc31.x86_64

I have another machine (a server) running 5.7.9-100.fc31.x86_64 and it does the pgrep in about 10-12ms with roughly the same number of processes (~260).

Just weird.

I tried kernel 5.7.11 on this laptop and it made no difference - pgrep was still about 4 times slower than ps. Same result after I rebooted to 5.6.19. Same result from the console.

On my raspberry pi-3b+ (4 cores) with raspbian, pgrep is about twice the speed of ps!!!

My laptop has an Intel i7, 8-Gb, 4-cores with hyperthreading and about 270 processes running

The server is i5, 8-Gb, 4-core and about 265 processes running

The pi is 1-Gb, 4-core and about 133 processes running

EDIT: I upgraded to kernel-5.9.16-100.fc32 and now pgrep is only about 3x slower than ps!!

EDIT2: a bit more info. strace on pgrep gives this:

     0.000089 openat(AT_FDCWD, "/proc/29/cmdline", O_RDONLY) = 4
     0.000071 read(4, "", 2047)         = 0
     0.000052 close(4)                  = 0
     0.503431 stat("/proc/30", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
     0.012402 openat(AT_FDCWD, "/proc/30/status", O_RDONLY) = 4
     0.002080 read(4, "Name:\tmigration/4\nUmask:\t0000\nSt"..., 2048) = 967
     0.000078 close(4)                  = 0

... so there's quite a delay in getting info on that process. There's no detail under that process so I don't know what it's about

wef
  • 452
  • 2
  • 6
  • I'd start with checking which versions of pgrep you are using and try using the same version on every machine to see if it makes a difference. – Lieven Keersmaekers Jan 06 '21 at 07:50
  • Hmm - a friend tested his debian system which had the same pgrep (procps-ng-3.3.16) and he didn't see this problem. – wef Jan 06 '21 at 08:13
  • Note that `pgrep` is searching through a mush smaller input than `ps -ef`. Using `pgrep -f` would be a better comparison. Of course, this makes your observation even stranger... – terdon Jan 06 '21 at 11:29
  • 1
    Just timing 1 execution is not good. It allows for random influences to confuse the result. "Performance Analysis", which is what you're doing. Try 100 or more times. Use `/usr/bin/time`. – waltinator Jan 06 '21 at 18:51
  • waltinator - as I mentioned, the timings are 'representative' - of course I did multiple runs. – wef Jan 06 '21 at 23:46

0 Answers0