On Tuesday 26 January 2016 18:09:11 Nikos Mavrogiannopoulos wrote: > On Tue, Jan 26, 2016 at 1:08 PM, Rick van Rein <[email protected]> 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.
