Hi, I was under the impression that this, ` _ = s[10] `, happens at compile time. But that probably doesnt make sense. We dont know the length of all slices at compile time.
Then, what is this actually improving? Does the compiler see there will be a bound check, so it doesnt produce instructions for more bound checks? So the assembly or bytecode will be smaller. On Friday 11 October 2024 at 08:34:00 UTC+2 tapi...@gmail.com wrote: > On Thursday, October 10, 2024 at 11:51:02 AM UTC+8 Nico Braun wrote: > > Hi, recently I became very self aware of potential performance > implications my code might have. > > In go there are a few key concepts, like escape analysis and bound checks. > If you check the standard library, you can see it was coded with micro > optimizations. > > For example, disabling bound checks in some methods, by doing something > `like _ = s[10]`. > > > The line is not a no-op. It makes bound checks in advance to remove more > checks. > > > > Or trying to use function arguments that they will likely end up on the > stack and not on the heap, by playing the escape analyzer. I.e. pass buffer > to io.Reader. Or sometimes, dont pass interface because it is hard for the > compiler to understand that the interface doesnt escape. > > I wonder, if I code like this, is this considered premature optimization. > Or is more like good habbit? > > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/66f9b041-1857-470f-b6c3-ce91a6126c01n%40googlegroups.com.
