Loading credentials in verify callback just as needed ?

[B. Scott Michel]

On 8/31/2012 8:45 AM, Tim Ruehsen wrote:
> Am Thursday 30 August 2012 schrieb Nikos Mavrogiannopoulos:
>>> There are 150 certs at the moment.
>>> GnuTLS 3.0.22 uses ~1.8 millions of malloc()s to read these files in.
>>> OpenSSL just ~5.000.
>> Ouch. It's the libtasn1's operation that uses quite excessively malloc
>> to parse the X.509 structures and create a tree, but 1.8 million for 150
>> certificates seems too much. Most probably an optimization there would
>> eliminate the issue you see.
>>
>>> On my rather old AMD 2000+ it takes ~1s to load these.
>>> Using valgrind for development (wget1.14), it takes around 30-40s.
>>> See some output at the end of my inital post (i meant to write Wget1.14
>>> there, not mget1.14).
>> Ouch.
> Yes, ouch ;-)
>
> I took a look at libtasn1, and yes, the best thing would be a partial rewrite.
> Unlikely someone is doing that... a quicker way to speed up would be the use 
> of memory pools in libtasn1.
I'd hesitate before writing my own memory manager (essentially what
you're proposing with memory pools). There's a good chunk of literature
that demonstrates that customized memory management is inefficient. It's
also a good indication that there's a different problem that needs to be
addressed. If you're using Linux, malloc() is already managing pools of
memory, as is almost every other malloc() implementation since around 1990.

2 million malloc() calls probably needs to be fixed first. If that can't
be fixed, look at the algorithm and fix it. But think long and hard
before writing your own memory manager.


-scooter