> > 16412 des_read_password
> > 16412 des_read_2passwords
> > 8192 des_read_pw_string
> These three are large because of arrays that are absurdly long; 8k to read
> in a password!
Great. Just make sure that if you reduce them, you don't risk buffer
overruns. (That is, make sure to find what it is that sets the limit on what
can go into the buffer and adjust that code too if need be.)
> > 8204 probable_prime
> This one can be reduced by 4k by using an array of 16-bit ints instead of
> 32-bit ints.
Perfect.
> > 10284 BIO_vprintf
> Don't know about this one.
I've looked at this one. It's a bit tricky. The 10Kb number seems to be
arbitrary, so it's possible that it's safe to reduce it. If someone wants to
print more than 4Kb in one shot, they should be using a safe function that
takes a max length.
If it's felt taht 4Kb is not safe because there might be calls to
BIO_vprintf of objects larger than that, I'd suggest having a global static
buffer with a lock.
If the concurrency is an issue, then if the lock is locked, call 'malloc'
and use a different buffer for that call. That way, you keep performance
(because you rarely malloc/free) but you keep concurrency (because you can
malloc/free if you have to). Unfortunately, I don't think the SLL lock
libraries have a 'non-blocking lock attempt' function. It can be faked, like
this:
static char *MyBuf[10*1024];
static bool BufInUse=false;
char *buf=NULL;
bool i_got_buf=false;
LockSomeLock();
if(BufInUse)
{
UnlockSomeLock();
buf=malloc(10*1024);
}
else
{
BufInUse=true;
UnlockSomeLock();
buf=MyBuf;
i_got_buf=true;
}
/* use 'buf' here */
if(i_got_buf)
{
LockSomeLock();
BufInUse=false;
UnlockSomeLock();
}
else free(buf);
Note that the lock is only held for a brief instant. If you have atomic
increment/decrement or test-and-set type operations, you can avoid the lock,
but that's a platform-specific optimization.
You can also 'ifdef' around this code to avoid the locking and testing if
we're compiled single-threaded. In that case, you can just use the static
buffer directly.
By the way, don't be too afraid of using malloc/free. Anyone who cares
about performance should be using a fast allocator/deallocator anyway. (By
the way, now that memory is cheap, you may want to retune your allocators to
favor speed over size.)
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
