[PD] optimizing big patches

[Mathieu Bouchard]

On Sun, 9 Jan 2011, Pedro Lopes wrote:

> i Guess the question could go a bit further, how can we devise a 
> profiling system for a dataflow programming environment?

I made two or three of those... GridFlow had several incarnations of such 
a thing but it only worked for GridFlow's own objects.

Then I made one for the whole of Pd, and it's somewhere in the DesireData 
branch, but it caused occasional crashes for mysterious reasons, and 
no-one else looked at the code.

Here's a screenshot of the latter :

   http://artengine.ca/desiredata/gallery/simple-benchmark.png

You see that [cos] is over twice slower than [*] but [t f f] minus those 
two is also a lot, but that's the cost of message-passing, because [t f f] 
doesn't do any processing. And so on... the top number is the total time 
for the first message to "return" (every message-passing down a wire is 
accompanied later by an opposite movement once the job is done... that's 
"the stack").

GridFlow's profiler instead had a menu in Pd's main window which had a 
"reset" and a "dump" and the latter would print non-cumulative 
measurements (i.e. it doesn't include time in objects sent to) in the 
console (or in the terminal back when there wasn't a console) sorted by 
decreasing importance.

Ideally we would have both cumulative and non-cumulative figures, because 
neither is nearly as useful as both together.

  _______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC