Re: Heap32Next performance awful on 64-bit Win7 (Was: CryptoAPI calls failing in rand_win on Windows 7)

2009-11-13 Thread James Baker
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

Heap32Next performance awful on 64-bit Win7 (Was: CryptoAPI calls failing in rand_win on Windows 7)

2009-11-12 Thread James Baker
, James Baker j...@j-baker.org wrote: It's not the CryptoAPI calls that are taking time - nearly all of the time is spent within Heap32Next.  Thus my hypothesis is that CryptAcquireContextW or CryptGenRandom is failing, causing 'good' to be 0 and the heap traversal to be unbounded. I see

Re: Heap32Next performance awful on 64-bit Win7 (Was: CryptoAPI calls failing in rand_win on Windows 7)

2009-11-12 Thread James Baker
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

Re: CryptoAPI calls failing in rand_win on Windows 7

2009-11-11 Thread James Baker
? -Sandeep On Fri, Nov 6, 2009 at 11:45 AM, James Baker j...@j-baker.org wrote: Background:  Testing a Ruby app on 64-bit Windows 7 Ultimate, I found that OpenSSL::PKey::RSA.generate() was taking 98 seconds.  Jumping to C, sampling showed that the great majority of this time was spent in Heap32Next