Memory management

[RedXVII]

Ive realised that i *might* need some extra memory for some large buffers/arrays. Though i dont know how much i will need until the function calls/uses it. So, The idea i came up with is to allocate some memory with GlobalAlloc for this task. Though i want to keep the process efficient as possible so i have a query on memory management in windows.

Would it be better to have lots of "GlobalAlloc"s whenever i need it, to keep things nice and small?

eg.

Code Select Expand

  ;looks like i need 8 bytes of memory for this array
  invoke GlobalAlloc, GMEM_MOVEABLE or GMEM_ZEROINIT, 8
  ...
  ;looks like i need 16 bytes of memory for this buffer
  invoke GlobalAlloc, GMEM_MOVEABLE or GMEM_ZEROINIT, 16
  ...etc etc

-or-

To allocate a larger chunk of memory (which i might not actually need) and munch my way through it?

eg.

Code Select Expand

  ;Well, im probably gonna need loads of memory for these arrays/buffers
  invoke GlobalAlloc, GMEM_MOVEABLE or GMEM_ZEROINIT, 65535
  ...

Would it be bad on windows to have loads of globalallocs of a small size?

Also - any hints/tips are appreciated loads!

Cheers :U

[James Ladd]

Maybe this will interest you:
http://www.masm32.com/board/index.php?topic=5072.15

[RedXVII]

Cheers

[hutch--]

Red,

A couple of things, if you want to use GlobalAlloc() use it with the GMEM_FIXED flag, the rest are left overs from 16 bit windows. Something that will improve your performance is to allocate ahead with enough spare to keep adding data until you are close then reallocate to a bigger size again. It reduces the number of re-allocs you make by doing this.

Depending on what your demand is, have a look at some of the other strategies for memory allocation, HeapAlloc() has the legs for small repeated allocations where GlobalAlloc() is a good performer on large blocks. If you don't mind the extra work managing your own memory, a single large allocation where you keep track of pointers to parts of it usually outperforms many fragmentary allocations.

[RedXVII]

Thanks hutch!  :bg

[Ian_B]

If you don't mind the extra work managing your own memory, a single large allocation where you keep track of pointers to parts of it usually outperforms many fragmentary allocations.

Glad of that, it's the solution I chose for a very similar problem, where I couldn't know how much memory would be required in advance and I didn't want to risk (possibly hundreds of) thousands of small string allocations. I've been scared of using HeapAlloc ever since I saw there were specific API cals to deal with heap corruptions, which rather advertised an unreliability I didn't want to risk experiencing...  :eek

Ian_B