Cc: larsi@gnus.org, npostavs@gmail.com, 39413@debbugs.gnu.org,
chiaki.ishikawa@ubin.jp
From: "ISHIKAWA,chiaki" <ishikawa@yk.rim.or.jp>
Date: Mon, 16 Aug 2021 08:27:01 +0900
But if you look slightly above, you will notice CPU core #4 is used 100%
(!).
That is emacs process. No other process is running that earnestly at
that moment.
If we believe everything these tools show us, maybe. But those tools
suffer from the same problem Emacs does on a busy system: the tool
itself might not get CPU to update its data, so you actually see a
snapshot of what it saw last time it did get CPU.
PS: I found profiler-cpu-* functions, but I don't think it is wise to
run them during GC since they seem to allocate vector tables. However,
taking a snapshot of strack trace every now and then during GC seems
attractive for my investigation to figure out WHERE in GC, the excessive
time is spent.
Emacs built-in profiling will not help us here, because it cannot
profile below Lisp primitives.