Odd question maybe, but does the API call slowdown too when traversing other heaps (which carry fewer items)? I assume not, but since you tested this and I don't see that aspect in your blog. (Pondering what can be done here; when the answer is 'no' to previous it means the only way out is to 'measure' each HeapFirst/Next to see if it is a 'slow' one (plus of course watch the total time spent in the outer loop).
There's no way to get the total number of heap blocks up front, so we're somehow stuck with 'seeing what happens while we traverse' one way or another, to checking after only a few API calls whether it registers on the clock()/ticks radar or not might work out... which leads to the second question regarding your values: Are those time-per-API-call numbers averaged or does /each/ Heap32Next call take this long?! (I assume here the first ones are faster and time spent increases gradually while the list is traversed, but again, that's only assuming and no observation data to aye or naye that yet) If the initial calls are faster, then the solution is still kind of the same, but needs a little further thought; a hacky 'check first N for time spent' won't work. just thinking out loud here.... <slap self! /> Aw, heck, this is doing things wrong way around anyway: whether those two assumptions are correct or not, the scanner code shouldn't depend on those anyhow and be able to cope with either one; 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. On Fri, Nov 13, 2009 at 2:38 AM, James Baker <j...@j-baker.org> wrote: > I've confirmed my linear performance conjecture w/r/t heap objects. > Click here to see pretty pictures graphing my results: Oh yeah, to answer one Q in first post: it's not a very smart idea to strip out entropy collecting code sections; it's the slow way to arrive at an undesirably predictable random generator as you take away a chance to introduce some entropy, one scanner part at the time. It's perfectly okay to /add/ other sources, such as noise input from audio sources, etc. (A/D converter and analog h/w noise) but taking out should be done with trepidation. There enough horror cases about the ones that have gone that road before, so, unless there's no other way, no need to add to that collection. ;-) -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
