GlobalAlloc vs HeapAlloc speed test

[ecube]

I read on msdn that heapalloc is faster than globalloc so I wanted to find out by how much but when I try to speed test it just freezes my system. Be warned the code below brought my system to it's knees forcing me to reboot :( I know I didn't globalfree and heapfree but I don't see the point when the process exit rights after, unless theres some global pointer to them even after. Anyway if anyone can fix, would be much appreciated.

[attachment deleted by admin]

[six_L]

Code Select Expand

invoke HeapCreate,00000001h,1024,1024
mov mainptr,eax

it should be outside

Code Select Expand

counter_begin...counter_end

[ecube]

how can I speed test it then? HeapCreate is required inorder to use HeapAlloc(well...you could also use GetProcessHeap) but the point is in order to speed test HeapAlloc againts Globalalloc correctly both heap function have to be in there

[hutch--]

cube,

I forget the topic but a member did a set of memory allocation speed tests about 18 months ago that may be useful for your reference.

[ic2]

I wonder if this is it.  It could be another one on my machine from back around then.  I'm still looking.

[attachment deleted by admin]

[ecube]

alright thanks hutch and ic2, I looked prior to posting but I guess I didn't look hard enough. :wink ic2,I got the code you just posted to compile but it still doesn't work, just uses like 120k memory then crashes. I attached the edited sources and binary if it works for you guys please post results. The article in there tells me what I wanted to know though, so thanks again.  :U

[attachment deleted by admin]

[ic2]

I executed the test and all it seem to do was run in background.  It grit and grid like crazy eating up mem i guest.  No Messagebox, no nothing.

I think the problem is translating it to complete masm format.  I don't remember how to do it completely.. But now it comply than quickly crash when i execute it...

This is what made the difference for comply or not on my XP for starters ... staticbuf      byte   < >


MEMSIZE TEXTEQU <1024*1024*256>

; DATA? section

buffer      BYTE   256 dup (?)


;EXTERNDEF staticbuf:byte
staticbuf      byte   < >

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Look at this ... no .if and .ENDIF and other things and it still assembled???  Now i remember.  It's full of syntax errors, How the author made it work I'll never know. Probably build with Tasm and  tested on 9x only.. Like you said the Info is still good to rebuild from.

IF 0
   ; code to show where the various memory allocations go.
   invoke   wsprintf, offset buffer, CTEXT("%08X"), esi
   invoke   MessageBox, NULL, offset buffer, CTEXT("Pointer value"), MB_OK
ENDIF

[Human]

well first of all to benchmark something you should know how things work, and what do you need.
globalalloc is replaced by virtualalloc and that how mscrap suggests to use it, due global can be gone some day.

next benchmark what? allocation? ofcourse heapalloc should be faster, it doesnt need to update gdt what regions are used. you do it with createheap.

next heapalloc only is RW no execute

next heapalloc doesnt waste memory, you alloc 10 bytes you get 10 bytes in heap

next virtualalloc always alloc by paging so smalest used memory is 4kb, you alloc 10 bytes you get whole 4kb page

next virtualalloc next address is 64kb aligned due granurality, heap alloc i dont know 1 or 4 bytes align.

and at end alloc will benchmark api not alloc, windows alloc memory on 1st access not alloc.
so benchmark will be not accurate.

[ecube]

next heapalloc only is RW no execute

HEAP_CREATE_ENABLE_EXECUTE
0x00040000

"All memory blocks that are allocated from this heap allow code execution, if the hardware enforces data execution prevention. Use this flag heap in applications that run code from the heap. If HEAP_CREATE_ENABLE_EXECUTE is not specified and an application attempts to run code from a protected page, the application receives an exception with the status code STATUS_ACCESS_VIOLATION."

[BogdanOntanu]

There is no GDT update on VirtualAalloc or HeapAlloc. Win uses paging and does not touch GDT on such operations.

[hutch--]

just going from memory the tests that were done about 18 months ago showed some unusual things. The old GlobalAlloc() was very competitive when allocating fixed memory but large numbers of small allocations were better suited to HeapAlloc(). VirtualAlloc() muddled along somewhere in the middle, OLE string memory was slower than the raw memory allocation APIs as it appears to be doing more work behind the scenes.

The surprise performer on small uneven sized memory allocations was a design by Ultrano which kicked ass for work of this type.