GridFlow 0.4.0 - Profiling Performance

What is profiling?

It is about getting empiric metrics about the execution of a program. For example, find out which parts of a program consume the most time and/or memory. Usually it's about the time, and this is what GridFlow (0.4.0) now allows you to measure.

How to get those stats from GridFlow ?

• create a "@global" object and connect two messageboxes to it, "profiler_reset" and "profiler_dump". The first one resets all counters to zero. The second one gives a top of the busiest objects, with percentages.
• note that those results are global to a fts process. That is, if you start jMax only once at a time, *all* objects in all patches may be monitored (actually, only the GridFlow ones).

How do i interpret those stats?

• Note that some operations may not be monitored, and some of the monitoring may be buggy. I think it's not buggy, but I may be wrong.
• The current profiler uses a thing called RDTSC. This is a very high precision clock that is very fast to use. However, *major* imprecisions may come from the fact that an ordinary multitasking OS will run other tasks without stopping/resuming the clock. This may happen randomly; however, it has a much bigger chance of happening in [@in] or [@out].
• If you make sure that only the bare minimum is actively running on your computer, then [@out] (using x11) would include the time spent in the x11 server, except in some conditions.
• The profiler has an impact on the results of the profiler. The profiler includes half of its own influence in its own results, and disregards the other half (or so). Profiling shouldn't add more than 100-300 ticks per message (of which half is counted).
• Message-passing time is not counted at all. Only time actually spent inside GridFlow objects is counted. This may skew results.
• A grid requires 2 messages (begin and end) plus one message per packet (flow or flow2), where each packet contains at most 2048 numbers (adjustable limit), and normally a packet should be at least half that size unless it is the last one. On RGB grids of widths 640,320,160, the packet size will usually be 1920. A small grid (~2000 elements or less) is 3 messages; a large grid is 2 messages + 1 message per packet; for a very large grid, the latter number may be very big, so you could ignore the "plus two" part.
• The MHz speed of your computer is important in determining the real time consumption. Profiler results are in clock ticks. If you have a 400 MHz computer, then dividing by 400 will give you a time in microseconds (usecs).

Getting a frames-per-second measure

• Make sure no other programs are actively running.
• Set your [metro] to the lowest possible delay (for example, 1).
• hide your jMax console.
• Send an "option timelog 1" message to your [@out].
• Make sure all of the output window is visible on the screen.
• Activate your circuit.
• Wait for over 20 frames or 10 seconds, the longest of the two. waiting for even longer gives more accurate results.
• Deactivate your circuit.
• unhide your jMax console. Find the series of measurements at the end of the log. If one of the time differences (except the first one) is much larger than the others, you should redo the test from the beginning.
• the overall time difference is the end time minus the start time.
• the overall number of frames is the end frame number minus the start frame number.
• the FPS (frames/second) value is the number of frames divided by the overall time difference.

acceleration tricks

GridFlow 0.4.0 Documentation
by Mathieu Bouchard matju@sympatico.ca and
Alexandre Castonguay acastonguay@artengine.ca