Howard Chu <hyc(a)symas.com> 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.
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.