pgrep / pkillがpsよりはるかに遅いのはなぜですか？ [閉鎖]

私はこれがpgrep以前よりはるかに速いと思いましたが、ps -ef正反対でした。pgrep時間が約4倍かかりました。しかし、私のラップトップでのみ可能です。たとえば、次のようになります。

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

比較：

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

...上記の時間は一般的な作業を表します。

コンテキスト：

Linuxカーネル5.6.19-200.fc31.x86_64を実行するIntel i7ノートブック。

5.7.9-100.fc31.x86_64を実行している別のコンピュータ（サーバー）があり、pgrepほぼ同数のプロセス（〜260）で約10-12ms以内に完了します。

ただ奇妙です。

私はこのラップトップでカーネル5.7.11を試してみましたが、違いはありませんでした。pgrepそれでもpsより約4倍遅いです。同じ結果で5.6.19に再起動しました。コンソールの結果は同じです。

私のラズベリーパイ-3b +（4コア）とRaspbianでは、速度はpgreppsより約2倍速いです！

私のラップトップには、Intel i7、8-Gb、ハイパースレッディングを含む4コアがあり、約270のプロセスが実行されています。

サーバーはi5、8-Gb、4コアで、約265のプロセスを実行します。

パイは1Gb、4コア、〜133個のプロセスを実行

編集する：kernel-5.9.16-100.fc32にアップグレードしましたが、今はpgreppsより3倍遅いです！

編集2：追加情報。 pgrepのstraceは以下を提供します。

     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

...それで、プロセスに関する情報を取得するのにかなりの遅延が発生しています。詳しい過程が出ていないので何の内容なのかはわかりませんが