Open nikitacrit opened 2 weeks ago
During our initial benchmarking, we found that the mem
package was causing a performance degradation for workloads that used very small messages. This was due to the overhead of allocating a struct
which contained the reference count on the underlying byte slice, and a reference to the slice itself. To overcome this, we added this mechanism where we would not reference count byte slices which were under a predefined size.
We don't have plans to make this threshold configurable, but if there is a valid use-case for it, we will definitely consider it.
Could you please let us know why you want to tweak this threshold? Thanks
@PapaCharlie @dfawley
This issue is labeled as requiring an update from the reporter, and no update has been received after 6 days. If no update is provided in the next 7 days, this issue will be automatically closed.
@nikitacrit I would recommend doing some benchmarking with your usecase — if you vendor dependencies with go mod vendor
, you should be able to adjust the threshold to see if it'd actually be worth it.
Hi! Thanks for the new package
mem
and the optimizations associated with it. But there is one question, what is the reason for the restriction withbufferPoolingThreshold
viaIsBelowBufferPoolingThreshold
call? Is there a plan to add the api to change the threshold? Is PR welcome?