how do these throughput measuments really reflect on actual performance characterisitics?
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 you have 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 over it's appended to a BLT::Vector..the gui-msg are also sent to a textfile object to find actual size....
samples sizeK ms speedK/s
windows (win32-xp-sp2): 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, though).
Perhaps, I should ask windows expert users out there: do not you think this should be improved?