Use strings.Cut where possible #4470
Conversation
kolyshkin
force-pushed
the
strings-cut
branch
from
92d3c96 to
bf53e34
Compare
kolyshkin
force-pushed
the
strings-cut
branch
from
bf53e34 to
aeb74e8
Compare
kolyshkin
requested review from
dqminh and
rata
and removed request for
dqminh
|
@kolyshkin I guess this is due to performance? Did you run some numbers or we just tested before this is faster and we are just using strings.Cut in more places? IMHO, it would be nice to say the reason on the commits. If something breaks due to this, it would be nice to know that the commit just changed to this due to performance, so a revert is probably safe until a new fixed version is cooked. But that is not that easy to know if we don't explain why we change it in the commit. |
kolyshkin
force-pushed
the
strings-cut
branch
from
aeb74e8 to
732da9a
Compare
Thanks, this makes sense. Individual commit messages as well as this PR description updated; PTAL. |
kolyshkin
force-pushed
the
strings-cut
branch
from
732da9a to
ae23108
Compare
kolyshkin
force-pushed
the
strings-cut
branch
2 times, most recently
from
819df22 to
62a4183
Compare
|
@opencontainers/runc-maintainers PTAL. This is a minor cleanup, aiming for more readable and faster code with less allocations. |
kolyshkin
force-pushed
the
strings-cut
branch
from
62a4183 to
37fdfdd
Compare
| return nil, fmt.Errorf("invalid --cgroup argument: %s", c) | ||
| } | ||
| if len(cs) == 1 { // no controller: prefix | ||
| if ctr, path, ok := strings.Cut(c, ":"); ok { |
There was a problem hiding this comment.
I havn't checked that whether this will lead to some regressions or not, for example, if c == "a:b:c:d:e":
When using SplitN, cs[1] will be "b";
When using Cut, path will be "b:c:d:e".
There was a problem hiding this comment.
So, the old code would error out when c == "a:b:c:d:e".
The new code would not, assigning b:c:d:e to path.
To me, the new code is (ever so slightly) more correct, since : is a valid symbol which should be allowed in path.
Using strings.Cut (added in Go 1.18, see [1]) results in faster and cleaner code with less allocations (as we're not using a slice). This part of code is covered by tests in tests/integration/exec.bats. [1]: golang/go#46336 Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Nowadays strings.Fields are as fast as strings.SplitN so remove TODO. Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Using strings.Cut (added in Go 1.18, see [1]) results in faster and cleaner code with less allocations (as we're not using a slice). This also drops the check for extra dash (we're unlikely to get it from the kernel anyway). While at it, rename min/max -> from/to to avoid collision with Go min/max builtins. This code is tested by TestCPUSetStats* tests. [1]: golang/go#46336 Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Remove extra global constants that are only used in a single place and make it harder to read the code. Rename nanosecondsInSecond -> nsInSec. This code is tested by unit tests. Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
For cgroup v2, we always expect /proc/$PID/cgroup contents like this: > 0::/user.slice/user-1000.slice/user@1000.service/app.slice/vte-spawn-f71c3fb8-519d-4e2d-b13e-9252594b1e05.scope So, it does not make sense to parse it using strings.Split, we can just cut the prefix and return the rest. Code tested by TestParseCgroupFromReader. Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Using strings.Cut (added in Go 1.18, see [1]) results in faster and cleaner code with less allocations (as we're not using a slice). The code is tested by testCgroupResourcesUnified. [1]: golang/go#46336 Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Using strings.Cut (added in Go 1.18, see [1]) results in faster and cleaner code with less allocations (as we're not using a slice). This code is tested by TestStatCPUPSI. [1]: golang/go#46336 Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Using strings.Cut (added in Go 1.18, see [1]) results in faster and cleaner code with less allocations (as we're not using a slice). Also, use switch in parseRdmaKV. [1]: golang/go#46336 Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Use strings.Cut in ParseKeyValue and GetValueByKey. Using strings.Cut (added in Go 1.18, see [1]) results in faster and cleaner code with less allocations (as we're not using a slice). [1]: golang/go#46336 Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
kolyshkin
force-pushed
the
strings-cut
branch
from
37fdfdd to
247d92a
Compare
For the most part, this is a switch from
strings.Split[N]tostrings.Cut.Using strings.Cut (added in Go 1.18, see 1) results in faster and
cleaner code with less allocations (as we're not using a slice).
There are a few other cleanups and nits here and there.
Please see individual commits for details.