Announcement

Collapse
No announcement yet.

To ReAlloc or not to ReAlloc..

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

  • 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..


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

  • #2
    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


    Michael Mattias
    Tal Systems Inc. (retired)
    Racine WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      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..


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

      Comment


      • #4
        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


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

        Comment


        • #5
          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

          Michael Mattias
          Tal Systems Inc. (retired)
          Racine WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            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.


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

            Comment


            • #7
              Hi Borje

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

              Cheers

              Florent

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

              Comment


              • #8
                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).]

                Comment


                • #9
                  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

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

                  Comment


                  • #10
                    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).]
                    hutch at movsd dot com
                    The MASM Forum

                    www.masm32.com

                    Comment


                    • #11
                      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"..


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

                      Comment

                      Working...
                      X