Size of Libgcrypt (and other libraries) and subsequent performance

[Ashish Gupta]

HI Simon,

Thanks for the update. I am currently not in office, however will conduct
more experiments once I am back.

Meanwhile, the figures related to the run time overheads are most
intriguing. Any comparisions on the way openssl handles its randoms?

Regards,
Ashish Gupta


On 4/24/08, Simon Josefsson <simon at josefsson.org> wrote:
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080424/eda6920e/attachment.htm>