Roast v0.5.0, faster input conversion #1293
Conversation
Using the new `ToOPAInput` function from RoAST cuts the number of allocations related to input transformation in half. This doesn't constitute a bottleneck for command line linting, but will help the language server process files as quickly as possible on changes. Also convert a few bytes/string conversions to allocation-free variants. I don't think these matter much, but having them around will help remind us that's an option for when it does matter. Signed-off-by: Anders Eknert <anders@styra.com>
anderseknert
force-pushed
the
bump-roast
branch
from
aa6edd0 to
518f36c
Compare
| @@ -133,7 +134,7 @@ func Plan(ctx context.Context, path, rego string, usePrint bool) (string, error) | |||
| { | |||
| URL: "/url", | |||
| Path: path, | |||
| Raw: []byte(rego), | |||
There was a problem hiding this comment.
So there's one direction where no copy or allocation is happening, and I believe it's string -> []byte. Random SO answer. So does StringToByteSlice actually do something for us? 🤔
There was a problem hiding this comment.
That's about slicing a string though? 🤔
From the same answer:
Strings in Go are immutable. So to change a string you need to make a new string. However, strings are closely related to byte slices, e.g. you can create a byte slice from a string with
foo := `here's my string`
fooBytes := []byte(foo)
I believe that will allocate a new array of bytes, because:
a string is in effect a read-only slice of bytes
according to the Go Blog (see Strings, bytes, runes and characters in Go). In general you can use a slice to change the contents of an underlying array, so to produce a usable byte slice from a string you would have to make a copy to keep the user from changing what's supposed to be immutable.
But even with that in mind, it seems like in many situations these things don't show up in benchmarks at all in either direction. Perhaps the compiler can tell no modification happens and can optimize from there? I don't know. These don't really matter in the places where used in Regal, as all the hot spots are in OPA anyway... so I'm ambivalent.
Using the new `ToOPAInput` function from RoAST cuts the number of allocations related to input transformation in half. This doesn't constitute a bottleneck for command line linting, but will help the language server process files as quickly as possible on changes. Also convert a few bytes/string conversions to allocation-free variants. I don't think these matter much, but having them around will help remind us that's an option for when it does matter. Signed-off-by: Anders Eknert <anders@styra.com>
Using the new
ToOPAInputfunction from RoAST cuts the number of allocations related to input transformation in half.This doesn't constitute a bottleneck for command line linting, but will help the language server process files as quickly as possible on changes.
Also convert a few bytes/string conversions to allocation-free variants. I don't think these matter much, but having them around will help remind us that's an option for when it does matter.