This is a follow-up on #14837, which got closed due to a partial solution regarding the heavy use of heap memory allocation.
I've just been using the tool provided by @richsalz in #16540, compiled like this:cd test/gcc -g -I../include timing.c ../libcrypto.a -ldl -lpthread -o timing
Update: PR for tool is now in #18821, called timing_load_creds.
When run on current 3.x master, I typically get figures like these:
./timing_load_creds -wc certs/timing-cert.pem
user 0 sec 57846 microsec
sys 0 sec 69877 microsec
and
./timing_load_creds -wp certs/timing-key.pem
user 0 sec 95863 microsec
sys 0 sec 115708 microsec
Whereas with the latest 1.1.1 branch, I typically get for instance:
./timing_load_creds -wc certs/timing-cert.pem
user 0 sec 17389 microsec
sys 0 sec 17389 microsec
and
./timing_load_creds -wp certs/timing-key.pem
user 0 sec 14719 microsec
sys 0 sec 10223 microsec
BTW, on my Debian system times reported vary a lot between consecutive runs - I've copied some 'average' outcomes.
So with 1.1.1, cert and key loading appear reasonably efficient,
while since 3.0 loading a simple cert (including a public key) degraded by a factor around 3.5,
and loading a private key degraded by a factor of more than 6.
@t8m wrote in #14837 (comment):
The obvious reason being the change from legacy to provider based parsing of the public keys in certificates.
Apparently the inefficiencies are due to generalizing the loading mechanism using the provider mechanism and maybe the STORE API,
which appear pretty involved when having a look at the code and stepping through them while debugging.
Is this considered bearable?
Hopefully some further bottleneck(s) can be identified and removed.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3