[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