Ferdinand Prantl wrote:
[...]
What is interesting, 471 heap entries takes much more time than 506 thread entries. OK, I can understand the slowness, if many big heaps are present; this code is run the worst count_of_heaps * 80 times:
RAND_add(&hentry, hentry.dwSize, 5);
[...]
I myself have never seen such a slow RAND_poll, so I'd think the problem has to be located somwhere on your computer.
Well, I solved it for me by patching the openssl in our production as our release draws nearer and nearer. I am attaching the file with the extended logging and the diff to rand_win.c which turns the heap-walking off, if anyone are interested. I can also test it further, should you like to have more information.
thank you,
Ferda
My solution as well. On some machines, running a large number of applications with long heap chains, the startup delay was totally unacceptable (sometimes on the order of 30 seconds for slow h/w). Unfortunately, this is one of those field found issues as developer and test machines seldom natuarally have these configurations (and a bugger to track down). I also question the usefullness of such an entropy source, especially if it contains such a performance hit. I think a solution that marries entropy gathering with startup time might be nice, ie. watch the clock as you walk those lists and bail early if it's taking too long.
-lee ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
