trace.h dead?

[caxapexac]

https://emscripten.org/docs/api_reference/trace.h.html

Here are 3 ways of using this library:

1. Google extension https://github.com/google/tracing-framework which is dead 3 years ago and doesn't work
   Page reload loop when recording URL using WTF google/tracing-framework#589
2. Noname library https://github.com/waywardmonkeys/emscripten-trace-collector for python2 which is dead 6 years ago
   Here is a fork https://github.com/feserr/emscripten-trace-collector and it works with python3 but this whole server has ugly GUI and also it doesn't gives an ability to save the report to open it in google framework GUI
3. Manually embed google framework http://google.github.io/tracing-framework/getting-started.html which is a huge unflexible crutch.

The third way has just worked for me but it requires manually adding these scripts into debug builds which isnt really easy to use

[caxapexac]

3 more libraries:

• https://github.com/google/orbit but requires TCP https://github.com/google/orbit/blob/main/documentation/DOCUMENTATION.md#prerequisites
• https://github.com/yse/easy_profiler but TCP and uses std::thread
• https://github.com/wolfpld/tracy also looks cool but Standard streams issues on Emscripten when using Tracy wolfpld/tracy#477

[sbc100]

I don't know if the framework has many users. Certainly there only seems to be one very basic test that uses it: test/core/test_tracing.c.

I believe this library was originally written by @waywardmonkeys back in 2014, so perhaps he has some insight? Are you still using this library bruce? How about @juj, do you use this library?

[junyuecao]

I think it is lack of mantainance. I've used it for some time, mainly to find memory leak.
And I have to modify the emscripten-trace-collector or emscripten to make it partly working.
Another shortage is the lack of multi-threaded supporting.

[skelly-energid]

It also does not work if -sPROXY_TO_PTHREAD is used.

It seems https://emscripten.org/docs/api_reference/trace.h.html should be deleted. Its presence is misleading.

[waywardmonkeys]

I no longer work for the people that I wrote this for ... I could perhaps look at updating some parts of it ... but maybe there are better ways to do it all now these days?

[sbc100]

Given that we have lsan for leak detection these days and it doesn't seem like there is anyone using this, I think this might be good feature to consider for removal.

Perhaps (I hope) this is the kind of thing that could be built on top of emscirpten rather than within it?

[waywardmonkeys]

I have the time, so I'll submit a PR that removes this. :)

[waywardmonkeys]

So, the --memoryprofiler stuff uses the --tracing stuff under the covers (at least some of it). I'll look more into this in the coming couple of days (but not over the weekend).

[waywardmonkeys]

@juj @kripken @sbc100 Is the --memoryprofiler stuff maintained / working / desired? Just want to understand my parameters...

[sbc100]

I'm not aware of any users, but I have maintained it over time. If nobody is using it, it would be great to remove it. If folks are using it ... then perhaps we can reduce the tracing support to use the memory profiler and remove the public interface to it.

[juj]

--memoryprofiler (and --cpuprofiler and --threadprofiler) are definitely being used!

[badgermole]

I have the time, so I'll submit a PR that removes this. :)

I've also just spent a bit of time trying to get tracing to work (tried Address Sanitizer first, but failed to get it to work with our code base, so moved on to try trace). I agree - or at the very least, give a warning at the top of the tracing doc that points here.