btf: use recursion in coreAreTypesCompatible #1383
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
coreAreTypesCompatible currently uses two manually maintained stacks to traverse two types to compare. The original idea was that using stacks would somehow be more efficient or it'd be easier to understand than the recursive approach. Time has shown that this was probably not true. Using the stacks is both harder to understand and probably less performant than using recursion. This is because the runtime maintains a stack for us, which can be reused across many invocations. Allocating on the (goroutine) stack is also incredibly cheap. Rewrite coreAreTypesCompatible to use recursion to traverse the two types. Instead of using walkType we simply open code the switch cases for Pointer, Array and FuncProto. This isn't much code and gets rid of a bunch of complexity and allocations, especially for FuncParam. The depth check is removed completely. It's a hold over from libbpf, which probably uses it to avoid stack overflow. This isn't necessary in Go, since overflowing the stack is guaranteed to panic. Instead, we deal with cyclical types by maintaining a visited map. Signed-off-by: Lorenz Bauer <lmb@isovalent.com>
This was referenced Mar 20, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
coreAreTypesCompatible currently uses two manually maintained stacks to traverse two types to compare. The original idea was that using stacks would somehow be more efficient or it'd be easier to understand than the recursive approach. Time has shown that this was probably not true. Using the stacks is both harder to understand and probably less performant than using recursion. This is because the runtime maintains a stack for us, which can be reused across many invocations. Allocating on the (goroutine) stack is also incredibly cheap.
Rewrite coreAreTypesCompatible to use recursion to traverse the two types. Instead of using walkType we simply open code the switch cases for Pointer, Array and FuncProto. This isn't much code and gets rid of a bunch of complexity and allocations, especially for FuncParam.
The depth check is removed completely. It's a hold over from libbpf, which probably uses it to avoid stack overflow. This isn't necessary in Go, since overflowing the stack is guaranteed to panic. Instead, we deal with cyclical types by maintaining a visited map.