tfb at tfeb.org
Tue Apr 13 15:57:48 UTC 2010
On 13 Apr 2010, at 15:02, Daniel Weinreb wrote:
> Tim, Gary,
> Tim Bradshaw wrote:
>> .. and that's more-or-less the problem I came up with. An
>> implementation could, I think, provide some kind of "map-function-
>> over- all-the-objects-this-thing-refers-to" function.
> I agree. How about a generic function that takes
> object X and tells you (1) the size of the X, including all
> of the Lisp objects that make up X logically, and (2) all of
> the objects X refers to?
I'd like to see this, too, though I think two functions would be
better than one:
* immediate-size-of (x) tells you the size of x in some arbitrarily
defined units (which will always be bytes in practice)
* mapc-referents-of (f x) calls f on everything refers to and returns x.
I don't care what the names are, of course (except, not map-* since we
deliberately want to not return the list of referents).
> You mean, what if there is double-counting because
> object A refers to object B by more than one path?
Yes, and I agree that this is a caller problem, and they need to use
an occurs check which they implement.
> The generic function hides things like how hash tables
> are implemented, just as generic functions can hide
> other things about the implementation. Is that
> good enough?
I'm thinking of the case where there is significant shared structure
which should not be exposed: immediate-size-of will then overcount the
memory when it looks at multiple objects which are sharing this secret
I actually would vote to just not worry about that: probably this
secret-but-shared stuff is small.
> One potential problem here is that if your data structure
> uses symbols, it might be particularly hard to decide
> whether your data structure is "responsible" for the
> symbol, or whether the symbol was already created
Yes, there are many problems here I think.
More information about the Openmcl-devel