Skip to content

feat: use rc to avoid allocating a new string for extension_id #615

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

Closed

Conversation

maxday
Copy link
Contributor

@maxday maxday commented Mar 9, 2023

Issue #, if available: potential fix for #614

Description of changes:
Using a RC around the extension id.
Now it clones the RC for each event which is way lighter than cloning the full extension_id string

⚠️ this is a breaking change as LambdaEvent is public

By submitting this pull request

  • I confirm that my contribution is made under the terms of the Apache 2.0 license.
  • I confirm that I've made a best effort attempt to update all relevant documentation.

@@ -221,6 +222,7 @@ where

let extension_id = register(client, self.extension_name, self.events).await?;
let extension_id = extension_id.to_str()?;
let extension_id_rc = Rc::new(String::from(extension_id));
Copy link
Contributor

Choose a reason for hiding this comment

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

isn't String::from(&str) an allocation anyways? can we make the extension_id field an &str?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

  • yes you're right but it's done only once (outside the loop) instead of doing it for every received events
  • I tried to make it a &str but this introduces a lot of lifetime-related code, was a bit less readable (IMHO) and also introduces a breaking change that's why I went with the Rc<String> path

Copy link
Contributor Author

Choose a reason for hiding this comment

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

what do you think @greenwoodcm?

Copy link
Contributor

Choose a reason for hiding this comment

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

ok i think that seems reasonable. is this change non-breaking?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

no it's not, I put a warning in the description but this basically modifies the public extension_id field in LambdaEvent from String to Rc<String>

Copy link
Contributor Author

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 you @greenwoodcm ?

@maxday maxday requested a review from greenwoodcm April 3, 2023 14:24
Copy link
Contributor

@calavera calavera left a comment

Choose a reason for hiding this comment

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

The extension id is a random string assigned to an extension when it's registered by the runtime to accompany a function. Every time the extension is registered, it receives a new random id.

When I added that field to the event, I thought it could be useful at some point. After further thinking, I don't believe it's really useful for anything worth exposing externally, it should just be an internal implementation detail.

Since this is going to be a breaking change anyways, I'd be more in favor of removing it completely.

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.

3 participants