circe is very slow when reconnecting to znc bouncer

[glasserc]

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 with error in process filter: Quit were produced.) Then I ran profiler-report (and then profiler-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 from shorten-strings (and in particular shorten-walk-internal).

It seems like there's repeated shortening of the same set of tracking-buffers. At the moment, my tracking-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.

[glasserc]

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.

[wasamasa]

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.