Size of Libgcrypt (and other libraries) and subsequent performance
simon at josefsson.org
Thu Apr 24 13:37:15 CEST 2008
Simon Josefsson <simon at josefsson.org> writes:
> Anyway, running callgrind on these binaries would be interesting... next
Which gave some interesting results. I don't know how to cut'n'paste
from kcachegrind, but I'm attaching a gzip'ed callgrind.out in case
anyone want to into more details. The top functions are:
26.60% transform (libgcrypt)
24.20% mix_pool (libgcrypt)
19.71% add_randomness (libgcrypt)
17.67% _gcry_rmd160_mixblock (libgcrypt)
15.47% do_fast_random_poll (libgcrypt)
14.24% asn1_find_node (libtasn1)
6.17% asn1_delete_structure (libtasn1)
Unsurprisingly, the randomness functions in libgcrypt take up most of
the time. Libgcrypt's random function mixes the pool a few times, which
explains the uses of hashing and in particular RIPE-MD-160.
What's surprising is that libtasn1 takes 14% of the time to parse the
certificate. However, I think we need more evidence to start optimizing
that -- it is a one-time startup cost and wall time elapsed time is
It is funny that the gnutls function that takes the most time is the
global deinitialization function!
The other gnutls functions are related to sorting the cipher suite
during the handshake. It can probably be optimized a bit, but I'm not
sure it is worth it.
Improving the randomness stuff is likely to give much better return of
investment. There seems to be plenty of evidence now that we should do
something about that.
The openssl kcachegrind output wasn't very readable since I'm using
More information about the Gnutls-devel