> Ger Hobbelt <g...@hobbelt.com> wrote: > Odd question maybe, but does the API call slowdown too when traversing > other heaps (which carry fewer items)?
Yes. This surprised me, but Heap32Next takes the same amount of time to execute when traversing the 2nd heaplist (which has 15 items) as it does the 1st heaplist (which has a million items). > Are those time-per-API-call numbers averaged or does /each/ Heap32Next > call take this long?! Each and every call takes the same long amount of time. To me, this indicates that the time spent is not actually spent *finding* the next heap entry (as if we were traversing a linked list to get to our destination), but in allocating (to the nearest 2^N) space for and/or recording info about every heap entry in every heap list. > an adjustment to keep the rand collecting scan within reasonable > bounds is well feasible (no hard upper limit, though, because, ah, > 'granularity' there is the time one (slowest) API call takes, no > matter how the solution is coded. It would definitely be easy to constrain the number of heap entries checked even further, based on time spent in the inner loop, but doesn't that run into this: > Oh yeah, to answer one Q in first post: it's not a very smart idea to > strip out entropy collecting code sections ... If we limited the inner loop to 1 second as we do the outer loop, we'd effectively be cutting out (in this case) 79 of the usual 80 bytes of entropy which, as you say, makes one trepidatious. RAND_poll appears to gather randomly varying amounts of entropy, basically "what it can grab in a few seconds". Is there a minimum effective amount of entropy that is known? The ideal thing is to add another source of entropy to compensate, but that's not something that's within my capabilities or time limits right now. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
