Size of Libgcrypt (and other libraries) and subsequent performance

[Simon Josefsson]

Simon Josefsson <simon at josefsson.org> writes:

> Anyway, running callgrind on these binaries would be interesting... next
> step.

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:

97.25% main
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)
8.64% malloc
6.75% free
6.17% asn1_delete_structure (libtasn1)
6.11% strcmp
5.89% _gcry_randomize
5.54% _asn1_remove_node
5.38% _gcry_rmd160_hash_buffer
5.24% md_final
4.72% rmd160_write
4.55% _gcry_rndlinux_gather_random
...
3.80% gnutls_global_deinit
3.77% strdup
3.67% _gnutls_supported_ciphersuites_sorted
3.67 _gnutls_qsort
...

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
likely small.

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
stripped libraries.

/Simon