-
Sun 2019.02.03
Thank you @Gordon for the clarification in #13 That and @allObjects eGetSizeOfText.js should make things clearer.
'@Robin, I don't get what is messing with you...'
'Memory not freeing up after call to E.getSizeOf() anomaly''If you keep that in a variable, it eats up space'
Over thinking perhaps? When
E.getSizeOf()
is used as a command in the console left pane, and is able to complete (depth) without error, it is as a status indicator, writes it's output to the Window and no JsVars are used.In the case when there isn't sufficient memory to create the output, as when I attempted to recurse a large class instance and at depth level two, although some level data was displayed, the function crapped out mid-way, finishing with the low memory error and cluttering memory. (maybe garbage collection doesn't/isn't occur?)
I'm modifing eGetSizeOfText.js to see what else I can glean from under the hood. Thanks for cranking that out.
@Robin, I don't get what is messing with you...
When you provide a depth parameter > 0 for E.getSizeOf(), you get JSON string back of object cluster, such as in the example output below. If you keep that in a variable, it eats up space as well until you assign something else to this variable. So no surprise you run out of memory...
In "Memory evolution..." section towards the end of the console output you see what each of the components cost to establish. As you notice there are hidden things because the numbers do not straight add up. Nevertheless the figures are close enough to explain where and on what the emory is spent on.
Since the memory tracking costs also memory, you have to adjust by it (mo - memory overhead - and you notice that it varies dependent on the length of the cmt comment assigned; cmt describes the activity that just happened to then show the increment in memory usage that activity did cost / consume in memory).
Console output: