Preallocate space for variables in run_context #1364
No reviewers
Labels
No labels
FreeBSD
Kind/Breaking
Kind/Bug
Kind/Chore
Kind/DependencyUpdate
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Windows
linux-powerpc64le
linux-riscv64
linux-s390x
run-end-to-end-tests
run-forgejo-tests
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
forgejo/runner!1364
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "steveno/runner:preallocate_execs"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This should help with reducing allocations during runtime which,
in theory, could provide a performance boost. These changes were
recommended by the prealloc lint.
can you please extend PR description what this improves?
I re-enabled a lot of the linters provided by golangci-lint and realized I could correct a lot of the issues it highlighted.
@steveno wrote in #1364 (comment):
Nice! Can you include enabling the related linter into this PR?
1543ad3148a02fe2b742Since the group seems receptive to the changes, I've added more to make this MR worth merging.
I'd rather not for a few reasons. First, this MR doesn't correct all the issues for the reenabled linter and I don't want all the pipelines to start failing by default. Second, at least on my machine, the linter is acting a little goofy. For example, I updated
act/runner/run_context.go:809from0tolen(rc.ServiceContainers)and now its spitting this at me - which is obviously wrong.Finally, @viceice asked me to update the PR description. Do you mean the commit message or the blurb here on forgejo?
just a short description why this change is worth merging. it's not obvious from PR title/ commit message/ code change
a02fe2b74207bba2df35@viceice I amended the git commit message and force pushed. Please let me know if further adjustments are needed.
@steveno wrote in #1364 (comment):
why didn't you added it to the PR description above as told? I've done it now. it makes review much easier because you can see the description much more prominent
All of these preallocations are implemented slightly incorrectly, resulting in significant logic errors.
This will create an array of length
len(s.Runs), full of zero values. And then it will append new values to the end, resulting in an array that is2*len(s.Runs)long.What is intended here is
names := make([]string, 0, len(s.Runs)), which creates an array of length 0, but capacitylen(s.Runs)so that theappendstatement doesn't have to allocate memory.@viceice wrote in #1364 (comment):
I'm sorry, I was a little confused. Next time I'll make sure both are filled out more fully.
@mfenniak wrote in #1364 (comment):
This is a great catch! Did you catch this as part of the test suite, or did you just recognize I wrote them incorrectly?
07bba2df35220bcdb865Looks good to me, thanks for the contribution!
@steveno wrote in #1364 (comment):
Just code review. I'm pretty sure that many tests would have been broken, but I didn't trigger CI to run once I noted the problem. 🙂
@steveno wrote in #1364 (comment):
PR description is more important, because we mostly do squash merge, so only the PR description lands in default branch commit message. 🤗