Add return value for writeJSMemoryStats

[cag62]

Can you change
writeJSMemoryStats() (file: OOJSConsole.m)
to return the heap size it receives (but ignores) from
dumpJSMemoryStatistics() (file: OODebugMonitor.m)
OR add a fn similar to writeJSMemoryStats that doesn't write, just returns the heap size?
Having the actual number would take the guess work out of tracking garbage generation.

[AnotherCommander]

Before putting any work on this, can you please describe how you would want to use such a feature? Why is outputting the heap size in the log, as already is the case, not enough?

[cag62]

> Why is outputting the heap size in the log, as already is the case, not

enough? - detail is lost when rounded to MB - cannot assign to JS variable

>... how you would want to use such a feature?

- while optimizing Telescope oxp, I was able to reduce garbage generation from 0.813 M/s to 0.218 MB/s, the Resource scripts from 13.11 KB/sec to 1.635 KB/sec. I got these figures by writing heap size to the log every 5 sec and averaging, a tedious process. The code changes resulted from guess work and intuition. - with the proposed change, I could capture the heap size before each function call in a frame callback and actually *know* which is generating the most garbage. I could also use the numbers to gauge the impact of optimizations. There will always be some garbage generated, it's the nature of these types of languages. But by reducing the more egregious ones, we can greatly reduce the frequency of in-flight stutters produced by GC. I hope to be able to post some simple examples for our non-technical authors to avoid common pitfalls. Having a metric, like the profiler, can tell me which are worth the effort vs those that are just a waste of time.

…

On Mon, May 28, 2018 at 9:05 AM, AnotherCommander ***@***.***> wrote: Before putting any work on this, can you please describe how you would want to use such a feature? Why is outputting the heap size in the log, as already is the case, not enough? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#298 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeIyep3CsdeRE3q1XLtFA-3nfa1KBKBaks5t2_YDgaJpZM4UPFlC> .