Re: memory functions in lisp similar to sizeof, malloc etc. of C

(message (Hello 'Aman)
(you :wrote :on '(Sat, 14 Apr 2007 12:53:15 +0530))
(

AG> But I am a little surprised by the fact that lisp doesn't natively
AG> support finding size of objects in memory.

using LENGTH function you can find size of string, vector, array or
whatever. that value should be ok for any algorithms you implement.

you might complain that this does not directly report you amount of
bits/bytes. but that value is implementation-dependant. you should not use
it in any portable algorithm. if you're really interested how much space it
actually uses, you can check your implementation's manual (or maybe source
code in some cases). on some systems sizeof(char) == 1, on other it might be
2 and even 4. some implementation might not support directly storing unboxed
values in array.

actually, there's absolutely NO WAY to find out how much space does data
occupy. even in C -- there is overhead for memory block align, for
supplementary heap structures etc. so, C won't tell you how much space does
your structure occupy. in fact, C won't tell you how much space did you
allocate. there's no standard function for this. Microsoft C has _msize --
but it's not portable to use it.

so, your surprise comes from general lack of knowledge of programming
languages -- you do not know C as well.

however, we might need information about size of objects in memory to
determine how much such objects we can allocate. there is function for this
practical purpose -- it's called ROOM. it's not possible to use it's output
in algorithm, since it's obviously non portable, but one can use it for
analysis of performance on a concrete implementation -- e.g. allocate some
1000 objects and see how does it influence free/allocated memory. btw i'm
using it quite intensively when programming some high performance
applications.
one can say that it would be better if ROOM return some number that can be
used inside algorithms -- for example, for planning cache size etc. but it's
damn hard to return any sensible value -- memory allocations are very
complex and it's extremely hard to predict how many objects it's possible to
allocate on heap. (it's not a problem of Lisp -- there is such thing as
address space fragmentation on OS level, so even if you have 500 MB free you
can fail to allocate some 10 MB continuous space). it's not even possible to
use free memory value for some heuristics -- on modern operating systems
virtual memory backed up by disk is frequently used, so OS and Lisp
implementation that works on top of it can report lots of free memory, but
if one uses it swapping will happen, and performance will drop terribly, up
to the point when application is not usable.
thus, it's easy to understand why there is no API for memory management in
standard Common Lisp -- if somebody really needs it badly, he can use
features of concrete implementation.

so, we can summarize that 'size of object in memory' is very vague value
even for C, and certainly high-level abstraction of Common Lisp make it even
more vague. it's possible exactly know all 'sizes of objects' only for such
low-level language as assembler, and only if you are not using high-level
operating system with virtual memory etc.

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"I am everything you want and I am everything you need")


.