feat: use sync.Pool to reduce alloc

[ethan256]

use sync.Pool to reduce alloc on conn.Receive.

[kung-foo]

Hi @ethan256, do you have some real-world motivation for wanting to introduce a pool?

[ethan256]

Hi @ethan256, do you have some real-world motivation for wanting to introduce a pool?
When I pressure tested it, I found that the program has a high GC percentage, and its pprof results are as follows:

Modified results：

[magiconair]

@danomagnum is this something the server could benefit from as well?

[danomagnum]

I would think so. I'd have to check but it may automatically benefit from this to some extent since it uses the uasc module already.

[magiconair]

Could you have a look @danomagnum ? Then I'll merge it to v0.6.1

[kung-foo]

I'd like to see a bit more research into whether or not this is needed. sync.Pools have a lot of foot guns. I checked one of our busiest clients (a subscription with about 3000 notifications per second), and I see "gccpu_fraction": 0.0014583341353648874. I know this a N=1 argument, but for us, gc pressure is basically nil.

[magiconair]

I remember sync.Pool having issues. Is this something we could hide behind a feature flag? Would we want to?

[magiconair]

Hey @kung-foo , my keybase account got blocked when my laptop and phone got stolen. Can you send me an email to re-connect? Check your inbox. Sent you something to your github email account.

[danomagnum]

I took a look at it and there are a couple places it would as currently implemented impact the server. Mostly the readChunk function. I agree on needing more investigation though to make sure we don't leak any slice references that would then get put back in the pool and re-used while not actually free. The other encoding performance pull request (#726) seems like a better first approach to me and (without actually looking into it) I don't see why you couldn't combine them eventually - using a pool of streams instead of a pool of buffers.

[ethan256]

sure we don't leak any slice references that would then get put back in the pool and re-used while not actually free.

I agree with this, there are indeed some non-free slice being put back into the pool. Further testing and analysis is needed.