I've confirmed my linear performance conjecture w/r/t heap objects. Click here to see pretty pictures graphing my results:
http://thenewjamesbaker.blogspot.com/2009/11/performance-of-heap32next-on-64-bit.html On Thu, Nov 12, 2009 at 11:50 AM, James Baker <j...@j-baker.org> wrote: > Punchline: The time taken by a call to Heap32Next on 64-bit Windows-7 > SCALES (roughly linearly?) with the number of heap entries in the heap > list. This seems to be a serious problem that would affect (at least) > most 32-bit-compiled OpenSSL users on 64-bit Win7. > > I've cleared my accusation against the CryptoAPI functions - those are > working fine. The time is taken up by Heap32Next, even though good == > 1 and stoptime is set. The 1-second constraint on the number of > heaplists walked is ineffective because the time is all spent in the > inner loop, walking the first 80 heap entries in the first heaplist. > > By the time I got up to 4 million (2-byte) heap objects in my test > harness, each Heap32Next call was taking multiple seconds. It is not > the overall size of the heap that counts, but the number of heap > objects. The performance of each Heap32Next (the 1st versus the 80th) > is roughly the same. I do not know whether the problem is specific to > only 64-bit Win7 (due to WoW), or whether it applies to all Windows 7 > versions. > > What then is the fix? Sure, this may be a Windows problem, but > letting RAND_poll take dozens to hundreds of seconds is obviously not > acceptable. This problem is sort of related to previous "heap walking > is slooow" threads on this list dealing with lines ~500-515 in > rand_win.c, but we can no longer get 80 entries from the first list in > anything near 1 second. What would the cryptographic effect (on the > entropy of the randomness pool) be from cutting the heap traversal > entirely (i.e. cutting 80 bytes of entropy) - is that > cryptographically acceptable? Is there some alternate way of > traversing large heaps, or some alternate source of entropy we could > turn to? > > I have a single cpp repro file with a slightly chopped-down RAND_poll > ripped out of rand_win.c that I could pass on to any OpenSSL > developer/contributor. > > Thanks, > James ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
