Quick guess; the socket itself (at the OS level) has a fixed buffer size and if the sending process exceeds it it is suspended until the receiving process eats at least some of it. The receiving process is thus handed a truncated buffer.
There's not much way around this. One possibility (if indeed this is a serious efficiency issue) would be for Pd to append a "done" message to each batch up tcl to up-send. On the receiving end you could then just 'string search' to the last occurrence of the special string and send that text safely to the interpreter.
cheers M
On Sun, Jan 22, 2012 at 11:42:01PM -0500, Hans-Christoph Steiner wrote:
I've been trying to debug this really annoying issue. The [info complete] look in pd_readsocket was causing some drastic slowdowns on some GUI objects like Scope~, making them unusable. If you remove the [info complete] bracket from pd_readsocket, there are these intermittent Tcl stacktraces causes by messages from 'pd' to 'pd-gui' that get split in the wrong spot.
I have found one very interesting result: the break always happens at 48k. At least when I test with the bitmap-madness.pd patch that comes with tclpd. It is a good test patch because it causes heavy pd --> pd-gui traffic. So I've tried a bunch of things and not much really seems to affect it:
- in configure_socket, change fconfigure -buffering to "line"
- in configure_socket, add -buffersize 500000 to fconfigure
- in s_inter.c set GUI_ALLOCCHUNK anywhere from 1k to 64k
It seemed that lowering GUI_ALLOCCHUNK did make it happen more often, but always the break was exactly at 48k.
Anyone have any ideas?
.hc
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev