[Openmcl-devel] memory

Alexander Repenning ralex at cs.colorado.edu
Mon Apr 12 16:59:03 PDT 2010


sizeof is very handy 

There is a very simple version of the SIZEOF method in here: http://code.google.com/p/xmlisp/source/browse/trunk/XMLisp/sources/Lisp%20User%20Interface/specific/Mac%20CCL/memory.lisp

some examples:

(defgeneric SIZEOF (Object)
  (:documentation "the size of object in memory. Object can be instance or type name"))


(defmethod SIZEOF ((Self float)) 4)
(defmethod SIZEOF ((Self double-float)) 8)
(defmethod SIZEOF ((Self fixnum)) 4)

(defmethod SIZEOF ((Type (eql 'float))) 4)
(defmethod SIZEOF ((Type (eql 'double-float))) 8)
(defmethod SIZEOF ((Type (eql 'fixnum))) 4)

(defmethod SIZEOF ((Self macptr))
  #-windows-target (#_GetPtrSize Self)
  #+windows-target (#_HeapSize (#_GetProcessHeap) 0 Self))


works for Mac/PC but needs fixing for 64/32 bit

Alex


On Apr 12, 2010, at 12:22 PM, Bill St. Clair wrote:

> It seems to me that what you need would be partially your own recursive
> data structure walker and partly a CCL-provided SIZEOF generic function.
> The SIZEOF generic function would take a single argument and return the
> number of bytes used by that object alone, but not anything it
> references. Your function would walk one of your data structures,
> calling sizeof on each Lisp object that you consider to be part of that
> one user-level data structure and summing all the results.
> 
> I sent in my last reply the code for SIZEOF on a CCL standard CLOS
> instance. Adding a full-featured SIZEOF generic function to CCL would
> likely be useful, and is probably not very difficult. You could do it
> yourself with a little routing around in the CCL source code. Or maybe
> somebody else on the list would like to make a portable version.
> 
> -Bill
> 
> On 4/12/10 10:16AM, Joakim Sandgren wrote:
>> In my case I have an object that contains all structures and data for a
>> whole musical composition.
>> parts, measures, notes, pitchvalues mapping tables...
>> It would be good to be able to see the "footprint" of different types of
>> solution.
>> as you are always confronted with either big size and high speed, or
>> smaller size and more calculations and then slower speed.
>> 
>> sincerely
>> joakim
>> 
>> 
>> Le 12 avr. 10 à 06:45, Gary Byers a écrit :
>> 
>>> When people ask questions like this, they usually means something
>>> like "what's the total size of this object, plus the size of all
>>> things that
>>> it transitively and uniquely references ?"
>>> 
>>> Another way of asking that is to ask "if the object in question became
>>> garbage, how
>>> much memory would be freed by the GC ?"
>>> 
>>> (let* ((obj (make-instance ...)))
>>> (gc)
>>> (let* ((with-obj (%precise-size-of-allocated-memory-at-the-moment)))
>>>  (setq obj nil)
>>>  (gc)
>>>  (let* ((without-obj (%precise-size-of-allocated-memory-at-the-moment)))
>>>    (- with-obj without-obj))))
>>> 
>>> There's no such function as the one that I'm calling
>>> %PRECISE-SIZE-OF-ALLOCATED-MEMORY-AT-THE-MOMENT; it's very hard to
>>> measure this in CCL (because of threads and because of other issues.)
>>> We're also assuming that OBJ is the only thing that becomes garbage
>>> between the two GCs, and we're assuming that that object isn't sitting
>>> in some machine register even after we set the variable OBJ to NIL.
>>> Neither of those assumptions is valid.
>>> 
>>> I don't want to say that there's no reliable way to answer this
>>> question in general, but it's much, much harder to answer than it
>>> might appear to be at first glance.
>>> 
>>> There are some heap-analysis utilities described at
>>> <http://trac.clozure.com/ccl/wiki/MemoryUtils> (some of them are
>>> currently x8664-Linux-specific); none of them try to answer this
>>> question, but they do try to answer some similar questions.
>>> 
>>> 
>>> 
>>> --On April 11, 2010 4:50:23 PM +0200 Joakim Sandgren
>>> <joakim at joakimsandgren.com <mailto:joakim at joakimsandgren.com>> wrote:
>>> 
>>>> Hi,
>>>> Are there a way to see how big in Kb  or bytes a clos object is ?
>>>> 
>>>> 
>>>> sincerely
>>>> joakim
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Joakim Sandgren
>>>> joakim sandgren musik
>>>> 42, rue de Maubeuge
>>>> 75009 Paris
>>>> France
>>>> +33 (0)1 45 26 43 90
>>>> info at joakimsandgren.com <mailto:info at joakimsandgren.com>
>>>> http://www.joakimsandgren.com
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 
>> Joakim Sandgren
>> joakim sandgren musik
>> 42, rue de Maubeuge
>> 75009 Paris
>> France
>> +33 (0)1 45 26 43 90
>> info at joakimsandgren.com <mailto:info at joakimsandgren.com>
>> http://www.joakimsandgren.com <http://www.joakimsandgren.com/>
>> 
>> 
>> 
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

Prof. Alexander Repenning

University of Colorado
Computer Science Department
Boulder, CO 80309-430

vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20100412/843e06cc/attachment.htm>


More information about the Openmcl-devel mailing list