On-demand feature struct allocation #696
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
LCOV of commit
|
kilroyd
reviewed
Aug 19, 2024
core/feature.go
Outdated
| @@ -71,20 +67,14 @@ func (f *Features) Init(properties *config.Properties, list ...interface{}) { | |||
| for i, featureName := range properties.FeatureList { | |||
| fields[i] = reflect.StructField{ | |||
| Name: featurePropertyName(featureName), | |||
| Type: reflect.TypeOf(singleFeature{}), | |||
| Type: reflect.PointerTo(propsType), | |||
There was a problem hiding this comment.
I guess we need to use PtrTo if we're still supporting go versions before 1.18
There was a problem hiding this comment.
Yep - done :)
Bob's conditionals in modules ("features") can use significant amounts
of RAM during build.bp parsing - each config option spawns a new struct
containing a copy of each build property, resulting in a multiplicative
impact on memory consumption.
Fortunately, close inspection of Blueprint's "unpack" code reveals that
we can instead pass in a nil pointer to the struct, instead of
initialising the properties for each conditional feature, which will
cause property structs to be allocated only when actually used in the
build.bp file.
Use this in Bob by making the property struct for each feature a nil
pointer to the property struct type, instead of a fully-instantiated
interface{} wrapped in a BlueprintEmbed.
Signed-off-by: Chris Diamand <chris.diamand@arm.com>
Change-Id: I42e432fcaa8f1f5cd48ba01c53cb95ce5109aa07
chrisdiamand
force-pushed
the
feature_struct
branch
from
4065645
to
23dbdf5
Compare
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.
Bob's conditionals in modules ("features") can use significant amounts of RAM during build.bp parsing - each config option spawns a new struct containing a copy of each build property, resulting in a multiplicative impact on memory consumption.
Fortunately, close inspection of Blueprint's "unpack" code reveals that we can instead pass in a nil pointer to the struct, instead of initialising the properties for each conditional feature, which will cause property structs to be allocated only when actually used in the build.bp file.
Use this in Bob by making the property struct for each feature a nil pointer to the property struct type, instead of a fully-instantiated interface{} wrapped in a BlueprintEmbed.
Change-Id: I42e432fcaa8f1f5cd48ba01c53cb95ce5109aa07