On 2021/08/12 16:10, Eli Zaretskii wrote: >> Cc: larsi@gnus.org, npostavs@gmail.com, 39413@debbugs.gnu.org, >> chiaki.ishikawa@ubin.jp >> From: "ISHIKAWA,chiaki" >> Date: Wed, 11 Aug 2021 22:41:56 +0900 >> >> What about the dump below, which was in the *Messages* buffer following >> dump I sent. >> I am afraid I picked up the wrong dump in my previous e-mail. >> >> Now, is "gc-elapsed" the elapsed time spent in the GC routine? >> If so, the two samples at the end of the dump here certainly look >> suspicious. > Yes, they show a couple of GCs that took about 150 to 200 sec. That > is indeed excessive, but gc-elapsed reports the wall-clock time, not > the CPU time, so if Emacs wasn't getting processing resources to run, > which could happen on a stressed system, that could explain the long > GC times. Note that other GC cycles, both before and after the 2 > problematic ones, took much less time. And the statistics returned by > memory-use-counts doesn't show any excessive number of Lisp objects; > in fact, my current Emacs session, which runs for 9.5 days, has an > order of magnitude more objects than what you show, and yet GC cycles > here are barely perceptible. > Hi, Thank you for your reply. So gc-elapsed is the elapsed wall-clock time. Is there a function to obtain CPU time in Emacs Lisp? On BSD, many years ago, I wrote a short routine that uses resource-related system call. I am using Emacs under linux now, and I assume similar calls exist under linux. I checked the manual. I will use getrusage(2), which seems to be BSD-compatible, to obtain the resource usage statistics and include the numbers in my post-gc-hook result. OTOH, I have always assumed that Emacs DID eats up CPU while longish GC. You may recall the graphics that showed the usage of a CPU core going all the way to 1000 in my previous e-mail (xosview). I am attaching it again. I used the graphics to show the memory usage (hand-drawn red circle) in my previous e-mai. 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. Thanks to many cores (actually I allocate 7 cores), the linux desktop was responding swiftly and xosview was recording system resource usage as the graphics shows. Only Emacs process could not respond to window repaint request from X when I re-arranged the windows layout, and that is why the Emacs window is garbled (hand-drawn blue circle was placed at the upper-left of the un-repainted area that remained black). I believe Emacs indeed was eating up the CPU time in a busy loop or deeply nested calls. (maybe a loop that could be handled in a for loop with a relatively shallow stack was handled by a recursive call that can be nested as deep as the list length?) Numbers from getrusage()　will give us additional insight on this matter hopefully. Thank you again for all your tips. Chiaki 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.