* Chris Kastorff: > If your program is spending that much time in GC, then you're likely > spending a lot of time with the pointer write barriers on, which slow > execution (for the benefit of having your code run at all during GC.)
Well, it's creating a lot of garbage, so I can't really complaint that it's GC-ing. > What happens if you run with GODEBUG=gcstoptheworld=1? That should help the > GC run faster and avoid slowing down your code's execution at the cost of > some latency spikes (which I think for your use case does not matter at > all.) It doesn't make a difference. With that setting, context switch rate as reported by vmstat is still very high, and the run time is about the same as without the setting. CPU utilization is still around 75%. > Consider using `sync.Pool`s to avoid so many allocations iff your objects > have an easily determinable lifetime; for example, you can reuse > `bufio.Reader`s by taking advantage of their `Reset` method. I don't have many files, just ~250 or so of them, so this does not matter. The ack channel inefficiency you have identified shouldn't matter for the same reason. I could probably cut the allocation rate somewhat if I find a different way to read packets with the OpenPGP library. Peeking under the covers, it seems to perform so internal reparsing of OpenPGP messages. In any case, I'm more interested in understanding this runtime behavior: the high context switching rate, and not fully utilizing available CPUs. If it helps, I can post exact instructions how to reproduce this. (The key server dumps are publicly available.) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
