Add tracing tool to visualize program execution

[fjenett]

Gal wrote

Regarding design, I have some rough ideas which are different from the usual call-graph view. For example, a heat map as the background of the PDE that shows where the PC have been during the last execution. Or, a draggable "playhead" that the user can manipulate to control a small dot that follows a "line of execution" on top of the code. This can be taken even further if you save values of some variables on the stack. For example, if you have a function 'createParticle(float x, float y, float mass)' that is being called repeatedly by a particle emitter with different (maybe quite random) values, you could have statistics on these values over time.

[fjenett]

@galsasson there are several things i like about this.

Timeline

I am heavily looking at the developer tools in my browser and envy that we don't have something similar to the Timeline feature (inspect execution over time) in Processing. For us a "frame" really would be one draw() call and being able to see what has been called and how long it took would be very convenient for finding slow code ("don't load images from disk in draw()" problem beginners have).

Another aspect could be to be able to inspect values over time and see them develop. I envision this to be similar to an oscilloscope.

Being able to scrub on that timeline or even just revert values to a specific point time would be very interesting.

Tracing

A visual call graph might not be such a bad idea and would help both beginners (understand) and experienced users (documentation).

I'm not sure how a heatmap would help, would it be "time spent" or "how often called" based?

The sing-along jumping red dot seems a little too much like a gimmick to me. But maybe that is just me ... or the image of it.

[galsasson]

Just found out about the Timeline in chrome, thanks @fjenett!

I like the draw() call as a frame, I think it makes a lot of sense in debugging slow code. The oscilloscope view for values over time is exactly what I was imagining.

Regarding the heatmap: I have seen beginner programmers that have parts in their code that they think is being executed but is not (happens when you practice copy&paste coding), or overly nested if/else statements (logic is hard when you start programming). It can be valuable just to know which code is executing and which is not. I think it make sense for the heatmap value to be based on one frame. So if a section is being executed once every frame it will get a medium intensity. High intensity for code that executes many times over the course of a frame, and lower for code that executes every number of frames. This tool will show which code is busier and give you a feeling of which parts needs to be more optimized. I imagine the design to blend into the background in a non intrusive way (light monochrome palette below the code for example). Call graph is fine for more advanced programmers, but I think that if there is a way to keep beginners close to the code (like displaying the data on top or next to the code) it is much better.

What if we'll let the user the ability to add "tracepoints" to the code (in addition and in parallel to breakpoints). At every tracepoint, a timestamp and all (or some) of the values in the stack will be saved. Actually I just googled "tracepoints" and found it was added as a new feature to visual-studio 2008, worth looking at what they have. Does any of you know about that? If we'll have tracepoints, we can have a timeline, an oscilloscope for value changing, a call graph and much more.

[Manindra29]

+1 for the heatmap & tracepoints idea! Sounds neat!