Skip to content
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

Gzip schema and metadata to avoid ballooning memory requirements #139

Merged
merged 2 commits into from
Aug 26, 2020

Conversation

viveklak
Copy link
Contributor

@viveklak viveklak commented Aug 26, 2020

We hit golang/go#6643 when we compile with the uncompressed literal contents for schema and metadata.

With this the generated files with the literal bytes for schema and metadata are 14MB and 5.5 MB respectively. Last checked, the memory requirement at compile time was around 1 GB.

return errors.Wrap(err, "marshaling metadata")
}

if err = compressedWriter.Close(); err != nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if we return the error above? Should we close in defer instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was initially considering a defered close but a the close actually performs a final flush so we need it to be flushed before writing the serialized content. Also, if we return early, GC should be able to reclaim the buffers created earlier.

if err != nil {
return errors.Wrap(err, "marshaling metadata")
}
if err = compressedWriter.Close(); err != nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to make a helper method here somewhere in utils? I don't have a string opinion though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can consider it as a subsequent step if this seems like a sufficient workaround. I have a feeling we might have to do some more maneuvering before a release here.

@viveklak viveklak merged commit 4cab51a into master Aug 26, 2020
@pulumi-bot pulumi-bot deleted the vl/CompressSchemaMetadata branch August 26, 2020 21:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants