Howard Chu <[EMAIL PROTECTED]> writes: > Yes, callgrind is pretty cool, much more useful than old gprof-style > profilers. Though as you note, the runtimes of any valgrind tool can > be pretty extreme. My tweaked version of FunctionCheck is also useful > when you can afford to compile an instrumented version of your > code. Faster runtimes in exchange for extra compile time - frequently > it's a worthwhile tradeoff. > > http://highlandsun.com/hyc/#fncchk
Interesting, does the code still run and is useful? The latest comment about it was from 2005. To be able to use it, I need to set up a useful benchmark environment first though. >>> Not being an TLS/SSL expert, I'm wondering why you need to add all >>> those certificates in the first place. I thought the whole point of >>> all those<subject hash>.<serial> links in /etc/openssl/certs (or >>> whatever) was that a client could find a CA certificate simply by >>> hashing the subject. >> >> GnuTLS doesn't support hashed certificate directories. Further, TLS >> servers need to send a list of names of trusted certificates to clients, >> so the server has to open and parse all local trust roots anyway. Right >> now, this is done for clients too, since the relevant code in GnuTLS >> doesn't know whether it will be used as a client or server. I hope the >> new code will be fast enough so that it isn't a bottle-neck. I suppose >> that it could be optimized further, so that it isn't done for clients at >> all, but let's not optimize prematurely. > > You're already approaching GnuTLS version 2.4. If optimizing now is > premature, when will it actually be time to optimize? If anyone wants to contribute by profiling/optimizing something in GnuTLS, doing it now is fine with me. /Simon
