Does anyone have any guidelines, recommendations, or rules of thumb for maximizing efficiency within PD?
For example: Which operations/objects/externals/GUI elements are most efficient and which are most costly? Is it extra costly to introduce an object that listens for input like keyname, midiin? Is using graph-on-parent costly? Are colors costly? Are there any general strategies that you use for keeping things fast and efficient?
Also, on a somewhat related note: Under which operating system does PD run the fastest (for a given hardware configuration)?
Thanks, -Bill
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, but very difficult to compare different cpu, systems, soundcards... for the meantime, william, you can use the dsp-object, which could bring you a little forward. marius.
----- Original Message ----- From: "William Fields" bill@teamtechno.com To: pd-list@iem.kug.ac.at Sent: Saturday, January 25, 2003 6:02 AM Subject: [PD] Maximizing Efficiency
Does anyone have any guidelines, recommendations, or rules of thumb for maximizing efficiency within PD?
For example: Which operations/objects/externals/GUI elements are most efficient and
which
are most costly? Is it extra costly to introduce an object that listens for input like keyname, midiin? Is using graph-on-parent costly? Are colors costly? Are there any general strategies that you use for keeping things fast and efficient?
Also, on a somewhat related note: Under which operating system does PD run the fastest (for a given hardware configuration)?
Thanks, -Bill
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
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