perf: improve ada::can_parse
#674
Conversation
…de for a can_parse verification
|
I created a copy of the parse function and moved to the checkers file, I've been profiling it and commenting the code I don't think we need for this scenario. It's still like a POC, there might be a better place to put it, also even a better function name, I am still poking around. |
|
Benchmarks main branch: current branch: |
|
instead of creating a copy of it, we could also just add a parameter to the parse_url function, like store_values=true, and for the can_parse we set it to false. |
|
one example from main branch, |
|
I think we may want to keep... template <typename result_type = ada::url_aggregator>
result_type parse_url(std::string_view user_input,
const result_type* base_url = nullptr);as you have done, at least initially, so we don't mess up our signatures and it is less invasive. But we could add... template <typename result_type, bool store_values>
result_type parse_url_impl(std::string_view user_input,
const result_type* base_url = nullptr);And then the implementation of template <typename result_type>
result_type parse_url(std::string_view user_input,
const result_type* base_url) { return parse_url_impl<result_type,true>(user_input); }and This should be nice because Thoughts? |
|
nice!! it looks good to me |
|
@lemire's suggestions looks really good, and this is amazing work @CarlosEduR. Thank you for doing this! I'm so excited! |
|
I appreciate the support, guys... I am working on it. 👨🏻💻 |
|
with these small changes we go from this: to this: |
|
I've noticed the For instance right here, by adding the |
|
current perf report: 
|
In your example, it is called when I am somewhat surprised that we are frequently setting the hostname to the empty string. But if it is common, then we can certainly try to optimize it. |
I updated the code a little bit more and ran a benchmark to check, seems most of it is coming from the Benchmark result: |
src/parser.cpp
Outdated
| } else { | ||
| url.consume_prepared_path(view); | ||
| ADA_ASSERT_TRUE(url.validate()); | ||
| if (store_values) { |
There was a problem hiding this comment.
| if (store_values) { | |
| if constexpr (store_values) { |
There was a problem hiding this comment.
No reason, I'll update it.
src/parser.cpp
Outdated
| ada_log("QUERY update_base_search completed "); | ||
| if (fragment.has_value()) { | ||
| url.update_unencoded_base_hash(*fragment); | ||
| if (store_values) { |
There was a problem hiding this comment.
| if (store_values) { | |
| if constexpr (store_values) { |
There was a problem hiding this comment.
I just noticed and understood this comment, nice! I noticed you mentioned the update_unencoded_base_hash, and I'd like to confirm some other cases. For instance, update_base_pathname and update_base_search would be methods we want to avoid for the can_parse as well, right?
if constexpr (result_type_is_ada_url) {
url.path = base_url->path;
url.query = base_url->query;
} else {
url.update_base_pathname(base_url->get_pathname());
url.update_base_search(base_url->get_search());
}
url.update_unencoded_base_hash(*fragment);
return url;
|
@CarlosEduR Can you also share before/after when you share your benchmark result? It's hard to understand the impact :-) |
sure... currently: before after |
|
Is this ready to land? @CarlosEduR @lemire? |
Yeah, I can say it is. There might be more places to avoid allocation still, but I don't think they'll change the perf that much. |
src/parser.cpp
Outdated
| url.update_base_search(helpers::substring(url_data, input_position), | ||
| query_percent_encode_set); | ||
| ada_log("QUERY update_base_search completed "); | ||
| if constexpr (store_values) { |
There was a problem hiding this comment.
this if statement seems like a duplicate. there is already an if statement that checks for store values couple of lines ahove
|
Last benchmark before after |
Relates to: #377