Closed glasserc closed 5 years ago
I guess this might be a duplicate of #286. Sorry, it's only in filing the bug that I realized what I needed to search for.
From experience, the memory option in the profiler isn't terribly useful and you won't miss on anything important by using the CPU option only.
I use znc to maintain a permanent presence on IRC to a bunch of channels even as I change physical location, suspend my laptop, etc. I use circe to connect to this bouncer. I have znc set up to keep a log of messages on those channels, and when I reconnect, it plays back messages that happened since I was online last. When this happens, emacs CPU usage spikes to 100% for a while -- several minutes sometimes. Among other problems, when this happens sometimes gnutls crashes, which means that I'm not even connected and I have to start over.
I finally decided to take a profile. I started profiling with
profiler-start
for both CPU and memory. Then I reconnected circe and after a few minutes of unresponsiveness/CPU time, I held down Ctrl-G until I was able to regain responsiveness. (Lots of messages witherror in process filter: Quit
were produced.) Then I ranprofiler-report
(and thenprofiler-report-write-profile
to save them for this issue). It seems to me (without knowledge of the circe codebase) like the problem is GC due to a large number of allocations, with the majority coming fromshorten-strings
(and in particularshorten-walk-internal
).It seems like there's repeated shortening of the same set of
tracking-buffers
. At the moment, mytracking-buffers
is pretty small:Its value is ("#fx-team" "#phabricator")
. I often have as many as 30ish channel/query buffers open, although most aren't that active.Here's a representative (memory) profile:
circe-mem-profile.txt
And here's a CPU profile, in case it's helpful: circe-cpu-profile.txt
I'm running emacs 26.1 and circe "2.10" from elpa circe-20180525.1231.