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. |
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 <[email protected]>
Nowadays strings.Fields are as fast as strings.SplitN so remove TODO. Signed-off-by: Kir Kolyshkin <[email protected]>
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 <[email protected]>
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 <[email protected]>
For cgroup v2, we always expect /proc/$PID/cgroup contents like this: > 0::/user.slice/user-1000.slice/[email protected]/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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
kolyshkin
force-pushed
the
strings-cut
branch
from
732da9a
to
ae23108
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.