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

[build] Optimizations and Localization #555

Merged
merged 15 commits into from
Jun 3, 2022

Conversation

Thomas1664
Copy link
Contributor

  • Convert static const std::string to static constexpr StringLiteral
  • Convert const std::string& to StringView
  • Localize build.cpp
  • Use std::unordered_map instead of std::map

Note: Depends on #553

@Thomas1664 Thomas1664 marked this pull request as ready for review May 24, 2022 21:42
# Conflicts:
#	locales/messages.en.json
#	locales/messages.json
#	src/vcpkg/build.cpp
@Thomas1664 Thomas1664 requested a review from BillyONeal May 25, 2022 21:23
@Thomas1664
Copy link
Contributor Author

@BillyONeal I applied your suggestions. Can you review again?

std::map<BuildPolicy, bool> policies;
for (auto policy : ALL_POLICIES)
std::unordered_map<BuildPolicy, bool> policies;
for (const auto& policy : ALL_POLICIES)
Copy link
Member

Choose a reason for hiding this comment

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

If I'm not mistaken, this looks like it's being persisted to a file that we ultimately hash, so we needed the determinism std::map was giving us?

I'm not certain.

In general, I think swapping from map to unordered_map needs to prove that all places the map is being iterated don't care about order.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

build_info.policies is mainly used by post build lint. There is no other reference, so I don't think it's used for hashing. Just do a find all references.

@@ -287,7 +345,7 @@ namespace vcpkg::Build
{
msg::print(Color::warning, warnings);
}
msg::print(Color::error, Build::create_error_message(result, spec));
msg::println_error(Build::create_error_message(result, spec));
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
msg::println_error(Build::create_error_message(result, spec));
msg::println(Build::create_error_message(result, spec));

create_error_message already adds the error: if I am reading this correctly. Probably occurs elsewhere.

Copy link
Contributor Author

@Thomas1664 Thomas1664 May 31, 2022

Choose a reason for hiding this comment

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

Looking at Build::create_error_message, neither the function itself nor the corresponding message msgBuildingPackageFailed adds error: . I removed the prefix and added it to the calling code via println_error. Again, just use find all references.

Copy link
Member

Choose a reason for hiding this comment

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

Looking at Build::create_error_message, neither the function itself nor the corresponding message msgBuildingPackageFailed adds error: .

Ah, I see, today it adds the error prefix, but you changed it so that it does not.

Again, just use find all references.

There's no "find all references" from the code review interface.

{
auto it = fields->find(fieldname);
auto it = fields->find(fieldname.to_string());
Copy link
Member

Choose a reason for hiding this comment

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

This is now safe but I think whether it's a perf win is questionable, since a lot of the time fieldname is already going to have been a std::string. However, I think the interface change is an improvement so I'm OK with it. Engaging C++17 transparent map comparisons can be later.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is now safe but I think whether it's a perf win is questionable, since a lot of the time fieldname is already going to have been a std::string.

Even if it was a win, anybody would notice because there are other things that are much slower. I'm already working on a PR to speed up post build lint using concurrency for some checks.

@Thomas1664
Copy link
Contributor Author

@BillyONeal Can you please take another look again?

@Thomas1664 Thomas1664 requested a review from BillyONeal June 2, 2022 19:47
@BillyONeal BillyONeal merged commit 9ebcdff into microsoft:main Jun 3, 2022
@BillyONeal
Copy link
Member

Thanks :)

@Thomas1664 Thomas1664 deleted the optimize-build branch June 3, 2022 21:42
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