Release: hxScout v0.4.0

[Jeff Ward]

Hi all,

hxScout v0.4.0 is now live at hxscout.com with new file open/save dialogs (ala linc_dialogs) and is built with the newest hxcpp (which has improved GC performance, making hxScout faster!)

 

I'm also updating the website with a user guide -- it's a work in progress. :)

[Ian Harrigan]

Great work Jeff! A truly invaluable tool!

Can it be used to isolated mem leaks? Since you have save / load functions, is it also possible to somehow compare two of the files, that way might be able to islolate allocations that havent been GCd or something like that? Not sure if that idea would work, but is that type of feature (mem leak checks) planned?

Great work!

Cheers,
Ian

[Jeff Ward]

Thanks, Ian! Yes, the data's all there for detecting memory leaks, and I plan on making a "live object report" which will automate: for a given frame N, select frames 1 through N, show allocated objects minus collected objects.

Best,

-Jeff

[Jeff Ward]

BTW, even with hxScout in its somewhat rudimentary state, Lars Doucet has been hard at work optimizing OpenFL and HaxeFlixel using it: https://twitter.com/larsiusprime/status/641733491609104384

You do have to take into account that 1) profiling adds overhead (e.g. tracking allocations is the most expensive, and it inflates the Garbage Collector latency), and 2) reducing allocations/collections isn't the end-all be-all, but every little bit helps! (You can and should run the profiler with and without allocation tracking.)

It certainly has elucidated some interesting side effects of certain language or framework features. E.g. lots of unexpected things create dynamics or allocate arrays at the cpp level, and may be best avoided in critical code:

- Parametric enums create dynamics

- Lambdas / closures referencing local simple vars create arrays
- Typedefs create dynamics

- Map<Int, Int>.get() returns a dynamic Null<Int>
- Something about args for CFFI calls makes arrays (Joshua or Lars would know more)

- Map.keys() creates an Arary

- etc

These things aren't bad, but they help you know when and what to avoid, how to use a framework or library optimally, and where to spend your time optimizing.

Best,

-Jeff

[Lars Doucet]

@Ian:

https://github.com/james4k/hxcppObjectGraphViewer

This is what you want :) It's a bit rudimentary, but quite usable once you get it running. Basically, you compile your app using the noted hxcpp branch, and this define: -DHXCPP_GC_DUMP_OBJECT_GRAPH,

Then, while it's running, you compile & run the hxcppObjectGraphViewer app separately. It will pop open a dialog window looking for a csv file. Your main app, when compiled with the above settings, will dump a CSV file in its working directory every time a GC sweep happens and it will have the latest live object report for you there. I've found best results by running my app to a suspicious point, letting it sit there for a while to ensure a GC has happened, then close it. Then I open up the CSV file in hxccpObjectGraphViewer and take a peak.

[Lars Doucet]

And just to be clear, live object view would be suuuuuper sweet to have in HxScout as well :D