-
-
Notifications
You must be signed in to change notification settings - Fork 10.6k
Optimize with ossl un likely coveralls approach #27961
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
base: master
Are you sure you want to change the base?
Optimize with ossl un likely coveralls approach #27961
Conversation
Signed-off-by: Norbert Pocs <norbertp@openssl.org>
Signed-off-by: Norbert Pocs <norbertp@openssl.org>
Signed-off-by: Norbert Pocs <norbertp@openssl.org>
Signed-off-by: Norbert Pocs <norbertp@openssl.org>
d7a9337
to
b8c7f60
Compare
So if we know every call to a function is not likely e.g. ossl_prov_is_running(). Is the proposal to do this check everywhere? |
@@ -868,7 +869,7 @@ int OSSL_PARAM_get_uint64(const OSSL_PARAM *p, uint64_t *val) | |||
return 0; | |||
} | |||
|
|||
if (p->data_type == OSSL_PARAM_UNSIGNED_INTEGER) { | |||
if (ossl_likely(p->data_type == OSSL_PARAM_UNSIGNED_INTEGER)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a lot of similar ones in this file that aren't updated. I'd suggest staying consistent and doing all or none of these checks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's right, but the data says different. (Probably will need to updated the description and add more info, but for now tl;dr:) I checked the coveralls report, to check for hot-paths (depending on our test suite) and focused only on the most used lines. If you check this file, no other places have that huge usage as this one. I'm focusing only on the most used places where this optimization can really matter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure our CI tests are all that representative or normal use. They will be for this function (asking for it's primary type) but not more generally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that the test suite is not completely showing true usage, but it could show at least some data. It is very hard to get high amount of real data on this.
Signed-off-by: Norbert Pocs <norbertp@openssl.org>
Signed-off-by: Norbert Pocs <norbertp@openssl.org>
Signed-off-by: Norbert Pocs <norbertp@openssl.org>
Signed-off-by: Norbert Pocs <norbertp@openssl.org>
Signed-off-by: Norbert Pocs <norbertp@openssl.org>
b8c7f60
to
0dbd7f9
Compare
Updated the description. The output I get from the script locally on this branch is:
where the numbers at the end should be the if and else taken - but that's not correct. Still it gives a good idea and with some lookup in the coverage.json file, it is identifiable what's going on. |
I updated the description saying how was this outcome identified. We don't want to put this check all over the code, rather focusing on critical places |
I still need to find a way to properly benchmark this; so leaving it in draft for now |
Use ossl_(un)likely to optimize branch usage.
Fixes: openssl/project#1233
I focused on the hot-paths in this PR where the hits were above 100 000 000. These lines were identified by coverage reports on running the test suite. Then I wrote a script to get the lines from the coverage file. The script is:
Checklist