-
-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does per-type memory consumption make sense here? #9
Comments
Sure why not. Though how consistent are they about the breakdown of the types being counted? |
Consistent in what way exactly? I'm not sure I understood that bit... |
Like, what types of objects do they actually count separately in their statistics? Are they the same types for each implementation? |
Here's a bit of listing. SBCL
Allegro:
CLISP:
GCL (wtf?)
So it's usually the
There are lots of standard types, and these are listed everywhere. There are also implementation-specific types. So yes and no 🤷 |
The thing to me about exposing this as a portability library is that unless the types exposed are also portable in some way, there's not really any useful way for a user to process the output, other than to just... add implementation-specific branching again, which would defeat the purpose. |
Right, now I get why you were asking that. Well, we can always sort things by belonging to |
In the very least it would need to be documented which types can be expected and the structure of the returned alist/whatever. |
Yeah, sounds like a lot... |
Hi again! In the spirit of #7, does per-type memory consumption breakdown belong here? SBCL, ECL (non-Boehm), CLISP, and CCL (and Allegro, but I haven't disassembled this bit yet) all provide this breakdown in their
room
, so why not incorporate it too?The text was updated successfully, but these errors were encountered: