Thanks for your tips, Jonathan. Anyway, while you were writing the mail I was already doing a test patch where update times of a 32 million samples array and table are tested, see attached.
I ran the test with Pd-extended 0.43.1 and Pd-double on OSX. For an array with that length, update takes ~3 seconds. For a table displayed graphically, ~3.1 seconds. Surprisingly, drawing as points (instead of polygon) takes almost 5 seconds. The deviation between repeated measurements, a few dozen milliseconds, was about as large as the difference between Pd-extended and Pd-double. I've verified that double precision numbers are indeed displayed with a maximum of 14 significant digits in Pd-double.
I also checked the time for writing 32 million samples to a table without graphical display. This took ~170 milliseconds for Pd-extended and ~ 220 milliseconds for Pd-double.
Later I'll do another test where transmission over network is more specifically tested.
Katja
On Tue, Apr 10, 2012 at 7:05 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: katja katjavetter@gmail.com To: pd-list@iem.at Cc: Sent: Tuesday, April 10, 2012 9:45 AM Subject: Re: [PD] why does PD round numbers? (in tables, in messageboxes, etc)
2012/4/10 IOhannes m zmölnig zmoelnig@iem.at:
On 04/10/12 10:33, katja wrote:
i was talking about pd/pd-gui communication (and keep the number format for both saving and pd/gui communication the same). when displaying/updating a table every single number is converted to text using printf, send over the wire and then converted back to a number for drawing the table. it makes a difference if you have to transmit 44100 *4 bytes or 44100*12 bytes.
Ah I see. It is not uncommon to display complete audio files, much more than 44100 samples.
I've never seen a patch that _displays_ all the data for an array that large. To
transmit 44,100 drawing instructions you need a _canvas_ size of "44100" and
if anyone has actually needed to do that in a patch I'd really like to see it.
So all these samples are converted to text and back to numbers, as they go over the network?
No. See plot_vis inside g_template.c. There is not a 1-to-1 correspondence between # of array elements and rectangles/polygon-coords on the tk canvas (at least for garrays, not sure about data structures). If you create a 44100 element array and make the "size" field in that arrays canvas dialog "2", Pd will only send data to the gui for those 2 pixels, not for the entire array. However, it will loop through the entire array on the c side _every_ time plot_vis is called, in order to figure out what info should be sent to the gui.
For example: running with -d 3, create an array with 10,000,000 elements. Now make the "size" field in its canvas dialog "2". Select the array. Click an array key to move it. Notice the lag, but also notice Pd is only sending two commands to the gui to draw the elements. It's because Pd must loop through 5,000,000 elements before it hits the next pixel where it needs to send another drawing instruction to the gui!
(While in the end, only a couple hundred values are displayed). And every character goes through the loop in binbuf_text() with all it's cases... well that is a bottleneck which should not be further aggravated. At least this performance issue can be quickly tested, using Pd vs Pd-double. I'll make a test patch for that.
Keep in mind that you're using a horribly implemented feature of Pd to do your test-- that is, if you're using garrays. For example, moving an array shouldn't
send _any_ element data to the gui. It doesn't in Pd-l2ork because it just moves
everything by tag, using one line of tk, thus there is no bottleneck in that case.
A practical test I can think of to compare 4byte vs 12byte payload is
something like [metro 100]--[tabwrite~] animation for a visible garray. I'd be
curious to know if there is a significant performance difference there.
-Jonathan
Katja
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list