On Fri, Nov 13, 2009 at 6:34 PM, James Baker wrote:
[...]
> 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 alloca
> Ger Hobbelt 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
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 'meas
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 wrote:
> Punchline: The time taken by a c
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
James Baker wrote:
>
> The problem does occur with full admin privileges.
To be 100% clear, this is full admin with no UAC? UAC will drop privilege
of an app seemingly running as 'administrator'.
__
OpenSSL Project
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 the "entrycnt = 80" constraint on walking the l
>RAND_poll runs very quickly with a near-empty heap.
Do you mean that the calls
to Heap32First, Heap32Next, Heap32ListFirst, Heap32ListNext are failing? Can
you check the return values from these calls? (using GetLastError?). In any
case, the heap traversals are bounded by the 1 sec limit. Even if
