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

Early return when size == 0 #2009

Merged
merged 3 commits into from
Nov 28, 2022
Merged

Early return when size == 0 #2009

merged 3 commits into from
Nov 28, 2022

Conversation

372046933
Copy link
Contributor

What problem does this PR solve?

Issue Number:

Problem Summary:

What is changed and the side effects?

Changed:

Side effects:

  • Performance effects(性能影响):

  • Breaking backward compatibility(向后兼容性):


Check List:

  • Please make sure your changes are compilable(请确保你的更改可以通过编译).
  • When providing us with a new feature, it is best to add related tests(如果你向我们增加一个新的功能, 请添加相关测试).
  • Please follow Contributor Covenant Code of Conduct.(请遵循贡献者准则).

As pointed out by @Tuvie #1995 (comment), when IOBuf::append_user_data is called with size 0, we can do early return. This avoids unnecessary block memory allocation in the later.

@@ -1211,6 +1211,9 @@ int IOBuf::append_user_data(void* data, size_t size, void (*deleter)(void*)) {
LOG(FATAL) << "data_size=" << size << " is too large";
return -1;
}
if (!size) {
return 0;
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we need to call deleter here?

Copy link
Contributor Author

@372046933 372046933 Nov 23, 2022

Choose a reason for hiding this comment

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

Was deleter called in the original implementation when size is 0? It's better to keep the semantics as before.

Copy link
Contributor

Choose a reason for hiding this comment

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

I still think size==0 should return -1 rather than 0. If it is failed, it means IOBuf does not take this Block at all. It is the caller's responsibility to delete the buffer.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Tuvie Makes sense. Does return -1 break backward compatibility?
Also return 0 && call deleter means that IOBuf takes the responsibility to free the buff. This is consistent with the behavior before this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Tuvie Both free and delete can operate on nullptr. Do we have any other pitfalls calling deleter here?

Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't we move the deleter null check and assignment below before this change? Otherwise the data may be leaked if user doesn't pass deleter.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@zyearn Yes, before this change, when size equals 0, append_user_data relies on the default free to release user memory if deleter not specified. We should maintain the semantics here. CC @wwbmmm

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, we need to keep the semantics.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

LGTM

@wwbmmm
Copy link
Contributor

wwbmmm commented Nov 23, 2022

LGTM

@zyearn zyearn merged commit d0052a6 into apache:master Nov 28, 2022
@372046933 372046933 deleted the early_return_append_zero branch November 29, 2022 01:55
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.

4 participants