Loading credentials in verify callback just as needed ?
tim.ruehsen at gmx.de
Mon Sep 3 08:59:33 CEST 2012
Am Friday 31 August 2012 schrieb B. Scott Michel:
> > 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.
;-) I never said that I want to rewrite the standard memory manager.
The memory pool I think of is just a kind of aggregation of many small
allocations into one allocation.
E.g., you know that a ASN.1 DER buffer contains strings and that their summed
length (plus 0 termination bytes) can't exceed the length of the ASN.1 buffer.
Knowing that, you could allocate a memory chunk with the same length as the
ASN.1 buffer and throw all the found/needed strings into it, instead of using
x times strdup().
Of course, there are some disadvantages and such changes might even need
changes in the API or the applications on top. E.g. you can't call free() or
realloc() to free or resize a single string.
With that, a DER decoding theoretically just needs exactly one malloc().
Same with the DER encoding.
More information about the Gnutls-devel