On Sat, 25 Jan 2003, marius schebella wrote:
very good point, would it be possible to have a standardized measure-procedure for objects, and write down the cost of cpu-time of all (or some important) objects in a list? i think it is not difficult to measure,
For whomever may be interested in implementing this in PD:
GridFlow used to support this feature. I called it runtime profiling (because you get the results while the program runs, and you can reset the timers, and so on). Classic profiling is more like: you'd run PD once, and get a report after you shut it down.
There are difficulties with making the measures: all calls into any inlet and out of any outlet must be intercepted, and the clock must be looked at each time. You run into the issue that making the measures at all has an influence on the performance of your patch. To minimize that, there are three tricks i've found:
RDTSC, a Pentium opcode, because the latter performs no context switches. This is not portable, but I hear there are similar opcode in other modern machine languages.
going in and out of procedures. GridFlow happens to be following this since its first real version (0.2.0). Whenever it can, operations are vectorized on ~4000-byte chunks. However, this does not happen naturally in PD, on average: in the DSP, ~128-byte chunks are used, whereas ~4-byte chunks are used in the message system. Similarly, GridFlow may operate on small datasets (e.g. scalars!) if you tell it so, and will then have no choice but to use chunks of that size.
you get fuzzier values in a sense, but the measuring has less of an effect on the measures, so the net result may be more accurate. It could also be less invasive on the code; however, getting to know which object is currently processing is black magic unless you get some cooperation from the execution engine. That cooperation might be like: all calls are intercepted, but the intercepting doesn't read the clock, it just takes note of which object is the current one, and puts that in a global variable (which is then read by the profiler).
Mathieu Bouchard http://artengine.ca/matju