2 ms·

So the solution the article suggesting is to "Use a big buffer (and later slice it for each client(????)) instead of create buffer for each client"? If above i

by nirui 7y ago

So the solution the article suggesting is to "Use a big buffer (and later slice it for each client(????)) instead of create buffer for each client"? If above is true, then I have one question: What if some where down the line, somebody calls append on that buffer? bigBuffer := make([]byte, 1024) clientABuffer := bigBuffer[:512] clientBBuffer := bigBuffer[512:] clientABuffer = append(clientABuffer, []byte("Hello Client 2")...) // clientBBuffer will now be [72 101 108 108 111 32 67 108 105 101 110 116 32 50 0 0 .... even we didn't directly modify it. Could be a downside. https://play.golang.org/p/JiVKypGHQdR https://play.golang.org/p/JiVKypGHQdR

jerf 7y ago
"So the solution the article suggesting is to "Use a big buffer (and later slice it for each client(????)) instead of create buffer for each client"?" No, it's actually just "create a big buffer and don't drop the reference". It's never used for anything except changing some numbers the GC uses to do its logic. Since it doesn't actually end up in physical RAM, it's doesn't consume significant resources either. It's just a funny-looking way at the Go-languange-level to twiddle some numbers to make the GC act differently. Allocating a big slice and handing out chunks of it does have its uses, basically, arena allocation flavored by being used in a GC'd language. But that's not what this is.
- nirui 7y ago
  Oh I got it finally. I was wondering why the article does not mention how to actually _use (read/write)_ that buffer after it's been allocated other than just keeping it alive (and do nothing else). Thank you for sum thing up.