how do these throughput measuments really reflect on actual performance
his throughput measurements are awefully polite ...see below.
ie, is the windows tk gui getting bottlenecked by this?
it may begin by numboxes or sliders failing to update and progress until youhave to just wait it out or kill the app..
these are transfer rates for the connection from pd.38 to pd-gui,
measured on an 800MHz PC (the only box I have with windows):
this 'real-world' test uses 256 element lists-of-floats.. after trickling overit's appended to a BLT::Vector..the gui-msg are also sent to a textfile objectto find actual size....
samples sizeK ms speedK/s
11751 116 332 349.3975
51795 513 1573 326.1284
222743 2229 7072 315.1867
1404800 13722 51536 266.2605
2302720 (pd still at 100% after a couple mins)
linux (2.6.11-gentoo-r1 x86_64)
well, i tried to run the test patch, but pd keeps crashing with this:
*** glibc detected *** free(): invalid next size (fast):0x000000000372aad0 ***
we have a winner...Windows!!
windows xp, Miller's pdtcl.dll 430Kb/s
linux 2.4, Miller's pd-gui 24Mb/s
linux performs over 50 times faster... and I think it scales
(2.66MHz linux PC transfers 80Mb/s, no windows there to confirm,
Perhaps, I should ask windows expert users out there: do not you
think this should be improved?