Re: Efficiency of libtasn1?

[Tim Ruehsen]

On Tuesday 26 January 2016 18:09:11 Nikos Mavrogiannopoulos wrote:
> On Tue, Jan 26, 2016 at 1:08 PM, Rick van Rein <address@hidden> wrote:
> > Hello,
> > I've recently seen how libtasn1 works, and it seems to be a useful
> > tool.  What I don't understand is how efficient it works internally?  It
> > looks like it allocates lots of pieces of memory, and that might slow
> > down its performance in comparison to more dedicated (protocol-specific)
> > alternatives.  Am I mistaken?
> 
> That is true. For simple small structures a custom parser (e.g., the
> one included in nettle) would be much more efficient. Where libtasn1's
> power comes is when you have an enormous number of overcomplicated
> structures. Said that, allocation is not very expensive with modern
> libc's and my experiments replacing malloc with talloc_pool() in
> libtasn1, showed a slow down instead of speed up. Thus this part
> should could not be significantly optimized.
> 
> > If it is sufficiently efficient for processing of high-bandwidth
> > traffic, it might be interesting to implement an LDAP server that can
> > have plugins, in a similar fashion as libevtp.  Although OpenLDAP is
> > very flexible towards admins, it is not very friendly to developers who
> > want to plugin a subtree with special, dynamic behaviour.
> 
> I think the only way to know whether libtasn1 would add significant
> overhead to your app is to benchmark it. In TLS connections the
> libtasn1 part is not a significant overhead.

That depends on how you define 'TLS connection' in a practical use case.
Let's say you want to make a single HTTP request...

For example, apps using GnuTLS (gnutls-cli, wget, curl) need to preload *all* 
available CA certs before the first TLS connection. This sums up pretty much 
regarding calls to libtasn and underlying calloc/malloc.

When opening a TLS connection with gnutls-cli, calloc() alone takes 13% of all 
CPU cycles, asn_der_decoding2 + asn1_create_element taking 45% of all CPU 
cycles (calloc cycles included).

For a long standing process this does not matter. E.g. a TLS server just 
creating new connections has no issues with libtasn/calloc.
But for short-living / one-shot processes the design of your apps and 
dependent libraries really matters.

If in doubt, as Nikos said, benchmark your process.
What I did for this quick shot is

valgrind --tool=callgrind gnutls-cli www.amazon.de >/dev/null
valgrind --tool=callgrind openssl s_client -connect www.amazon.de:443

and displaying the results with kcachegrind.

Sorry for being slightly OT, but hope it helps designing/optimizing, Rick.

Regards, Tim

signature.asc
Description: This is a digitally signed message part.