New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/vuln: optimization opportunities #57357
Comments
Change https://go.dev/cl/460435 mentions this issue: |
Change https://go.dev/cl/460420 mentions this issue: |
This idea is currently blocked on VTA using both incoming and outgoing edges from the callgraph.Graph. If it only uses outgoing edges, we can benefit from only constructing the outgoing CHA edges, which is roughly what this suggestion is. In particular, |
Change https://go.dev/cl/460758 mentions this issue: |
Optimizes how sccs are internally computed by reducing the amount of maps created and map lookups performed. Between 4-10% faster on benchmarks of callgraph construction. Updates golang/go#57357 Change-Id: I0ecd92c32358a56d1cae67beb352ec15b7b4367e Reviewed-on: https://go-review.googlesource.com/c/tools/+/460435 Run-TryBot: Tim King <taking@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> gopls-CI: kokoro <noreply+kokoro@google.com> Reviewed-by: Zvonimir Pavlinovic <zpavlinovic@google.com>
Source(...) now builds the *ssa.Program and callgraph from the *ssa.Program in parallel with fetching vulnerabilities. Returns as soon as the vuln set is empty. Updates golang/go#57357 Change-Id: I310b93f7125b5edcc2a5744db9f9f595c70aa5d4 Reviewed-on: https://go-review.googlesource.com/c/vuln/+/460420 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com> Run-TryBot: Tim King <taking@google.com> Reviewed-by: Zvonimir Pavlinovic <zpavlinovic@google.com>
In principle, we can construct the incoming edges from outgoing, so I believe the VTA can be refactored to account for this. This construction would only be done for this different representation. I suspect it would be rather inexpensive. |
Another possible option would maybe be to have nodes for return values? Return statement values could flow into those nodes and when the calls happen we can connect the results to the return nodes. More nodes for doing fewer edges like a likely minor win. |
We could do that as well. I think this is also what naturally pops up when implementing invoke-group optimization. |
Refactors callee construction to create a function mapping a callsite to its callees. This consumes 4x less memory and is 37% faster than fully constructing a callgraph.Graph on a benchmark for a net/http server. If made public, this could be used to optimize the performance of vulncheck. Updates golang/go#57357 Change-Id: I42faa859d10f30361d3d497a81245af7f61e8a01 Reviewed-on: https://go-review.googlesource.com/c/tools/+/460758 gopls-CI: kokoro <noreply+kokoro@google.com> Run-TryBot: Tim King <taking@google.com> Reviewed-by: Zvonimir Pavlinovic <zpavlinovic@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Change https://go.dev/cl/461417 mentions this issue: |
govulncheck.DefaultCache interface was changed to return error. Update callsites. Notable changes: vulncheck performance improvements (golang/go#57357) https://go-review.googlesource.com/c/vuln/+/460422 https://go-review.googlesource.com/c/vuln/+/460420 store the vuln info cache under module cache directory https://go-review.googlesource.com/c/vuln/+/459036 https://go-review.googlesource.com/c/vuln/+/460421 Change-Id: Ie3816f31b4e1178bb2067cb09c1c726dd37fad55 Reviewed-on: https://go-review.googlesource.com/c/tools/+/461417 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> gopls-CI: kokoro <noreply+kokoro@google.com> Reviewed-by: Robert Findley <rfindley@google.com>
Source(...) now builds the *ssa.Program and callgraph from the *ssa.Program in parallel with fetching vulnerabilities. Returns as soon as the vuln set is empty. Updates golang/go#57357 Change-Id: I310b93f7125b5edcc2a5744db9f9f595c70aa5d4 Reviewed-on: https://go-review.googlesource.com/c/vuln/+/460420 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com> Run-TryBot: Tim King <taking@google.com> Reviewed-by: Zvonimir Pavlinovic <zpavlinovic@google.com>
Source(...) now builds the *ssa.Program and callgraph from the *ssa.Program in parallel with fetching vulnerabilities. Returns as soon as the vuln set is empty. Updates golang/go#57357 Change-Id: I310b93f7125b5edcc2a5744db9f9f595c70aa5d4 Reviewed-on: https://go-review.googlesource.com/c/vuln/+/460420 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com> Run-TryBot: Tim King <taking@google.com> Reviewed-by: Zvonimir Pavlinovic <zpavlinovic@google.com>
Source(...) now builds the *ssa.Program and callgraph from the *ssa.Program in parallel with fetching vulnerabilities. Returns as soon as the vuln set is empty. Updates golang/go#57357 Change-Id: I310b93f7125b5edcc2a5744db9f9f595c70aa5d4 Reviewed-on: https://go-review.googlesource.com/c/vuln/+/460420 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com> Run-TryBot: Tim King <taking@google.com> Reviewed-by: Zvonimir Pavlinovic <zpavlinovic@google.com>
Some ways we could make govulncheck faster, based on observations of a CPU profile:
The text was updated successfully, but these errors were encountered: