update:Reduce buffer allocation times to improve efficiency

[wzy2687]

在io频繁的场景中, 从客户端读取数据时, 减少内存申请次数, 提高效率.

[aceld]

@wzy2687 感谢提交PR， 辛苦 XL 有时间，抽空评估下 @xxl6097

[xxl6097]

在io频繁的场景中, 从客户端读取数据时, 减少内存申请次数, 提高效率.

Go的make相当C++里面的new，都会开辟新的内存空间，一般情况底层传输出去的buffer都是不同地址空间的，C++里面处理是用完delete，Go里面应该是自动释放。你的这个修改有经过多线程大量测试吗？

[wzy2687]

在io频繁的场景中, 从客户端读取数据时, 减少内存申请次数, 提高效率.

Go的make相当C++里面的new，都会开辟新的内存空间，一般情况底层传输出去的buffer都是不同地址空间的，C++里面处理是用完delete，Go里面应该是自动释放。你的这个修改有经过多线程大量测试吗？

go 的make 相当于cpp 的new, cpp中高性能要求的时候, 应该尽量减少new. 这里没有必要每次读数据就 make一个新的buf. 一直一个buf, 可以减少内存申请的次数. 这个似乎不需要大量测试.

[xxl6097]

在io频繁的场景中, 从客户端读取数据时, 减少内存申请次数, 提高效率.

Go的make相当C++里面的new，都会开辟新的内存空间，一般情况底层传输出去的buffer都是不同地址空间的，C++里面处理是用完delete，Go里面应该是自动释放。你的这个修改有经过多线程大量测试吗？

go 的make 相当于cpp 的new, cpp中高性能要求的时候, 应该尽量减少new. 这里没有必要每次读数据就 make一个新的buf. 一直一个buf, 可以减少内存申请的次数. 这个似乎不需要大量测试.

你没考虑，你make一块内存，被多个线程操作会出现什么问题吗？？

[wzy2687]

在io频繁的场景中, 从客户端读取数据时, 减少内存申请次数, 提高效率.

Go的make相当C++里面的new，都会开辟新的内存空间，一般情况底层传输出去的buffer都是不同地址空间的，C++里面处理是用完delete，Go里面应该是自动释放。你的这个修改有经过多线程大量测试吗？

go 的make 相当于cpp 的new, cpp中高性能要求的时候, 应该尽量减少new. 这里没有必要每次读数据就 make一个新的buf. 一直一个buf, 可以减少内存申请的次数. 这个似乎不需要大量测试.

你没考虑，你make一块内存，被多个线程操作会出现什么问题吗？？

懂了, 你说的是这个问题. StartReader 函数是一个协程入口. 每启动一个startReader, 就会对应一个buf. 所以应该不存在多线程操纵同一个buf.

[xxl6097]

在io频繁的场景中, 从客户端读取数据时, 减少内存申请次数, 提高效率.

Go的make相当C++里面的new，都会开辟新的内存空间，一般情况底层传输出去的buffer都是不同地址空间的，C++里面处理是用完delete，Go里面应该是自动释放。你的这个修改有经过多线程大量测试吗？

go 的make 相当于cpp 的new, cpp中高性能要求的时候, 应该尽量减少new. 这里没有必要每次读数据就 make一个新的buf. 一直一个buf, 可以减少内存申请的次数. 这个似乎不需要大量测试.

你没考虑，你make一块内存，被多个线程操作会出现什么问题吗？？

懂了, 你说的是这个问题. StartReader 函数是一个协程入口. 每启动一个startReader, 就会对应一个buf. 所以应该不存在多线程操纵同一个buf.

你先做测试吧，这个地方的改动影响是很大的

[wzy2687]

在io频繁的场景中, 从客户端读取数据时, 减少内存申请次数, 提高效率.

Go的make相当C++里面的new，都会开辟新的内存空间，一般情况底层传输出去的buffer都是不同地址空间的，C++里面处理是用完delete，Go里面应该是自动释放。你的这个修改有经过多线程大量测试吗？

go 的make 相当于cpp 的new, cpp中高性能要求的时候, 应该尽量减少new. 这里没有必要每次读数据就 make一个新的buf. 一直一个buf, 可以减少内存申请的次数. 这个似乎不需要大量测试.

你没考虑，你make一块内存，被多个线程操作会出现什么问题吗？？

懂了, 你说的是这个问题. StartReader 函数是一个协程入口. 每启动一个startReader, 就会对应一个buf. 所以应该不存在多线程操纵同一个buf.

你先做测试吧，这个地方的改动影响是很大的

这个影响大吗? @aceld

[wzy2687]

在io频繁的场景中, 从客户端读取数据时, 减少内存申请次数, 提高效率.

Go的make相当C++里面的new，都会开辟新的内存空间，一般情况底层传输出去的buffer都是不同地址空间的，C++里面处理是用完delete，Go里面应该是自动释放。你的这个修改有经过多线程大量测试吗？

go 的make 相当于cpp 的new, cpp中高性能要求的时候, 应该尽量减少new. 这里没有必要每次读数据就 make一个新的buf. 一直一个buf, 可以减少内存申请的次数. 这个似乎不需要大量测试.

你没考虑，你make一块内存，被多个线程操作会出现什么问题吗？？

懂了, 你说的是这个问题. StartReader 函数是一个协程入口. 每启动一个startReader, 就会对应一个buf. 所以应该不存在多线程操纵同一个buf.

你先做测试吧，这个地方的改动影响是很大的

这里理论上都没有冲突吧, 如果有, 请指出, 什么场景下, 会多协程操纵同一块buf.

[xxl6097]

在io频繁的场景中, 从客户端读取数据时, 减少内存申请次数, 提高效率.

Go的make相当C++里面的new，都会开辟新的内存空间，一般情况底层传输出去的buffer都是不同地址空间的，C++里面处理是用完delete，Go里面应该是自动释放。你的这个修改有经过多线程大量测试吗？

go 的make 相当于cpp 的new, cpp中高性能要求的时候, 应该尽量减少new. 这里没有必要每次读数据就 make一个新的buf. 一直一个buf, 可以减少内存申请的次数. 这个似乎不需要大量测试.

你没考虑，你make一块内存，被多个线程操作会出现什么问题吗？？

懂了, 你说的是这个问题. StartReader 函数是一个协程入口. 每启动一个startReader, 就会对应一个buf. 所以应该不存在多线程操纵同一个buf.

你先做测试吧，这个地方的改动影响是很大的

这里理论上都没有冲突吧, 如果有, 请指出, 什么场景下, 会多协程操纵同一块buf.

这个地方就算每次make，后面也会自动释放。你的改动是数据接收入口，如果这个地方出问题，影响大而且问题难查，必须做大量测试

[wzy2687]

你的改动是数据接收入口，如果这个地方出问题，

这个地方, 什么情况下会出问题. 如果你们有测试用例, 可以跑跑看.

[xxl6097]

你的改动是数据接收入口，如果这个地方出问题，

这个地方, 什么情况下会出问题. 如果你们有测试用例, 可以跑跑看.

从代码层分析，目前没什么问题。我的意思是你先做测试，发版本做测试这个流程没问题吧

[wzy2687]

这个地方就算每次make，后面也会自动释放

每次都make, 所以效率会低些, 这也是这个pr 的改进的点.

[wzy2687]

你的改动是数据接收入口，如果这个地方出问题，

这个地方, 什么情况下会出问题. 如果你们有测试用例, 可以跑跑看.

从代码层分析，目前没什么问题。我的意思是你先做测试，发版本做测试这个流程没问题吧

我自己已经在用了. 具体并发测试用例没有专门写.

[xxl6097]

你的改动是数据接收入口，如果这个地方出问题，

这个地方, 什么情况下会出问题. 如果你们有测试用例, 可以跑跑看.

从代码层分析，目前没什么问题。我的意思是你先做测试，发版本做测试这个流程没问题吧

我自己已经在用了. 具体并发测试用例没有专门写.

你自己在用，就先用一段时间，理论没问题，实际中没问题就合一下

[aceld]

conn.Read 如果每次读到的数据都从buffer[0]开始覆盖，将这个make放在for{}外层应该没问题。先merge，再观察。
感谢 @wzy2687 。 也感谢 @xxl6097 提出的风险。

[tonly18]

我在这里使用了sync.Pool，跑小半年了。