Re: reuse memory and unset seems slo

From: miguel sofer (msofer_at_users.sf.net)
Date: 01/11/05

  • Next message: David N. Welton: "Re: Action-oriented vs Object-oriented"
    Date: Tue, 11 Jan 2005 16:16:15 -0300
    
    

    mitch wrote:
    >
    > so to reuse memory, do I have to reassign new data to original name
    > assigned to the old listvar ?
    >
    >
    > or could I do something like:
    >
    >
    > set newlist_1 [ list 1 2 3 4 5 6 7 ... 999999 ]
    > unset newlist_1
    >
    > set newlist_2 [ list 1 2 3 4 5 6 7 ... 999999 ]
    >
    >
    >
    > will that reuse the memory?

    Yes. Depending en exactly what you are trying to do, there may be better
    ways.

    >
    > Does it go into sort of a common holding place called
    > "available memory for any variable in this program "

    We tend to call it "pool (or linked list) of free Tcl_Objs".

    >
    >
    > and a side note about something I noticed, is it takes almost as long to
    > do a
    > "unset varname" as it did to load it up. When there are millions of
    > list elements the time is surprizingly long.

    Yes. What is happening internally is:
       (1) every list element gets its reference count decreased, and the
    Tcl_Obj is returned to the pool if the refCount is now zero
       (2) the memory for the array of pointers is returned to the OS

    Depending on details, you may help the core omit step (2) (and the
    immediate alloc afterwards) if you are about to define a new list, by
    modifying in-place.

    >
    > In this same newsgroup someone tried to explain that to me a year or so
    > ago, but I still don't understand that. doesn't one pointer also point
    > to the next one ? So if you drop the first one you loose them all ?

    Nope - tcl lists are not implemented as linked lists, they are c-arrays.
    That is why they are so fast (constant time) to access by index.

    Note that even if it was a linked list, "drop the first and loose them
    all" sounds like a recipe for a very massive memory leak (except maybe
    in garbage collected environments).


  • Next message: David N. Welton: "Re: Action-oriented vs Object-oriented"

    Relevant Pages

    • Re: grow list by tail, pointer example recipe -- please comment
      ... manufacturing a pointer with that address. ... the next cons cell. ... believe these lists are in consecutive memory locations. ...
      (comp.lang.lisp)
    • Re: race on multi-processor solaris
      ... > Use a lock-free garbage collector. ... So what does protect the memory attached to the node? ... >>such linked lists, ...
      (comp.unix.solaris)
    • Re: Fast linked list
      ... > amounts of memory rather than huge chunks of it. ... random insertions into a vector/dynamic array are not as slow ... to cause a cache miss. ... some hard numbers on speed differences between lists and arrays. ...
      (microsoft.public.vc.mfc)
    • Re: Fast linked list
      ... > amounts of memory rather than huge chunks of it. ... random insertions into a vector/dynamic array are not as slow ... to cause a cache miss. ... some hard numbers on speed differences between lists and arrays. ...
      (microsoft.public.vc.language)
    • Re: Pointer To A Vector Elements While Still Adding
      ... As I understand it, when you add an element to the end of a list, memory is ... there is sufficient capacity. ... elements to 10,000 lists. ... better to allocate them statically). ...
      (comp.lang.cpp)