[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Size of Libgcrypt (and other libraries) and subsequent performance

From: Ashish Gupta
Subject: Re: Size of Libgcrypt (and other libraries) and subsequent performance
Date: Thu, 24 Apr 2008 18:02:22 +0530

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?
Ashish Gupta

On 4/24/08, Simon Josefsson <address@hidden> wrote:
Simon Josefsson <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]