Announcement

Collapse
No announcement yet.

To ReAlloc or not to ReAlloc..

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Borje Hagsten
    replied
    Thanks fellows. Nice piece of code there, Steve. Will come in handy,
    because I have discovered that even using POKE$ with STRING$() will
    use up double memory for a short while, since it obviously must need
    its own memory to store what it returns. Better and leaner to do it
    directly to existing memory block.

    Wow, seems I have to read up on memory handling in 32-bit Windows.
    Right now, I feel just like my old math teacher used to say, "this
    may seem easy enough, but just wait until I have explained it"..


    ------------------

    Leave a comment:


  • Steve Hutchesson
    replied
    Borje,

    To fill / clear an allocated memory block, the algo below should be fast
    enough, it clocked at about 190 meg / sec on my PIII. This is in
    MASM format but the conversion to PB inline code is easy enough,
    just change the MASM anonymous label [ @@: ] to a named label and
    change @B to the name of the label to jump to.

    Regards,

    [email protected]

    Code:
    ; #########################################################################
      
    memfill proc lpmem :DWORD,ln :DWORD,fill :DWORD
      
        mov ecx, ln         ; byte length
        mov eax, fill       ; fill chars
        mov edx, lpmem      ; buffer address
        add ecx, edx        ; offset for exit condition
      
      @@:
        mov [edx], eax      ; put fill chars at address in edx
        add edx, 4          ; increment edx by 4 (DWORD)
        cmp edx, ecx        ; compare to counter
        jbe @B              ; jump if below or equal
        
        ret
      
    memfill endp
      
    ; #########################################################################
    Smilies are a pain for code (GRIN)


    ------------------


    [This message has been edited by Steve Hutchesson (edited January 16, 2001).]

    Leave a comment:


  • Florent Heyworth
    replied
    Hi Borje

    when you call Global/Local alloc the memory is allocated from the
    process' default heap. As such you're more likely to see
    fragmentation using the default heap (since there are many
    different variables of varying length that need to be allocated
    and de-allocated) than if you create a separate heap using the Heap
    functions.

    Memory fragmentation is always an issue and you can't use Global
    /LocalCompact to compact memory since these functions are not
    supported in Win32.

    A reasonable strategy is to allocate various heaps each managing
    objects of the same size even if it means wasting memory since
    fragmentation is kept at a low level.

    Cheers

    Florent

    ------------------

    Leave a comment:


  • Borje Hagsten
    replied
    Interesting. So HeapAlloc should be faster then? Win32api.hlp
    says nothing about this, but it do say that "allocated memory
    is not movable", plus "Since the memory is not movable, it is
    possible for the heap to become fragmented."

    Not sure if that is bad or not. Maybe best to stick to LocalAlloc
    anyway..


    ------------------


    [This message has been edited by Borje Hagsten (edited January 16, 2001).]

    Leave a comment:


  • Florent Heyworth
    replied
    Hi Borje

    that's incorrect - in Win32 both Local and Global Alloc are mapped
    to the Heap calls.

    Cheers

    Florent

    ------------------

    Leave a comment:


  • Borje Hagsten
    replied
    Actually, you were right about POKE$, Michael. Thanks for the tip.
    Don't have to create a string to use it. POKE$ ptr, STRING$(Length, 0)
    works fine for zero fill. Good replacement for FillMemory and
    ZeroMemory API, since those are not included in winapi.inc.

    I'm trying to avoid as many loops as I can, for better speed.

    As for HeapAlloc - not the same as Local/GlobalAlloc. Memory
    will not be moveable, so the heap may end up becoming fragmented.
    Think LocalAlloc is best for this purpose.


    ------------------

    Leave a comment:


  • Michael Mattias
    replied
    Well, to re-size, I think you'll need to use the various xxxAlloc API calls.

    As far as resetting the memory to zero, if you can get a pointer to it you can always loop thru a DWORD at a time...

    Code:
    DIM foo AS DWORD PTR
    
    TheLoc = VARPTR(start of block)
    TheSize = (Length of block \ 4 )
    Trips = 0
    foo = TheLoc
    DO
     @foo = 0
     incr foo
     incr trips
    LOOP UNTIL trips > TheSize
    MCM

    Leave a comment:


  • jcfuller
    replied
    Borje,
    It is my understanding that in Win32 there is no difference between Global/Local.
    These are the old 16bit mem alloc routines that I believe call HeapAlloc.
    You may want to check out the heap functions. Why add another level of function
    calling to your program.
    Also Semen posted some code for mem allocation using ole.

    James


    ------------------

    Leave a comment:


  • Borje Hagsten
    replied
    Sorry, I guess I wasn't very clear there.
    Yes, I mean clear, empty from previous contents and in some cases
    also resize at the same time.

    To use POKE$, I need to create a string with same size. Will double
    the memory needs there for a while, which is not very good, since
    we can be talking about multi-MB memory blocks here.

    REDIM AT is out of the question. The memory block is the base for
    an editor control and works just like a normal String, or should
    I say, as base for an array of dynamic strings (lines in editor).

    The editor control has to be independent of Globals, so I use this
    approach and store the handle in a TYPE declared variable, with a
    pointer to that one stored in the extra bytes for the control window.

    Anyway, I have most of it working and it's just about as fast as
    using ordinary Global arrays or a String variable. You'll see what
    I mean, once I have it all ready..

    LocalFree/LocalAlloc works fine, as do LocalReAlloc. Like I said,
    it's just that nagging feeling about LocalReAlloc..


    ------------------

    Leave a comment:


  • Michael Mattias
    replied
    By "clear" do you mean de-allocate? Or do you mean reset the contents of the block to binary zeroes?

    If the latter, you can use POKE$ or RESET (DIM an array "AT thelocation").


    MCM


    Leave a comment:


  • Borje Hagsten
    started a topic To ReAlloc or not to ReAlloc..

    To ReAlloc or not to ReAlloc..

    I want to clear a memory block quickly. Does anyone know if using
    LocalFree/LocalAlloc is safer (or unsafer), than LocalReAlloc?
    (Local- of GlobalAlloc seems to be the same thing, or?)

    I've heard some rumours about "issues" with ReAlloc, like that it
    sometimes fails to reallocate to larger memory blocks, etc, but I
    can't find anything about it at MSDN, or elsewhere, so I thought
    I'd ask around to see if anyone knows anything about this.

    I have tried both and both seems to work fine. It's only that I
    have this nagging feeling that LocalFree/LocalAlloc is safer..


    ------------------
Working...
X