(Posting here rather than c.l.t because I believe this is an internals 
issue)

I want to process data received over the network in a safe interpreter 
(although for the purposes of this question, the safe-ness is 
irrelevant). Roughly speaking, I invoke the safe interpreter as

  safeinterp eval [list process_request $received_data]

What I've found is that invoking the slave interpreter in this manner is 
slower than processing in the same interpreter by two orders of 
magnitude or more. Here is a tkcon session simulating the issue:

(woof) 51 % interp create ip
ip
(woof) 52 % ip eval {proc slaveproc arg {}}
(woof) 53 % string length [set s [string repeat x 100000]]
100000
(woof) 54 % time {ip eval [list slaveproc $s]} 10
3335.4 microseconds per iteration

So roughly, 3.3ms to pass 100K into an empty proc in the slave. By 
comparison, passing it to a proc in the same interp (using eval for 
consistency)

(woof) 55 % proc masterproc arg {}
(woof) 56 % time {eval [list masterproc $s]} 10
9.3 microseconds per iteration

So use of a slave interpreter in this fashion is MUCH slower. That 3ms 
overhead makes this approach a non-starter in a web server environment. 
As a workaround, what I currently do is call the slave proc without any 
arguments and then have it call back to retrieve the data through an 
alias. This is only slightly slower (~15 microsecs) than the one interp 
case so acceptable but feels like a hack with unnecessary additional 
bookkeeping for the callback alias.

Timestamping the C code, the slowdown with the slave interp seems to 
happen because of shimmering in SlaveEval (the internal rep for the list 
is thrown away and converted to a string and then converted back in the 
slave).

FINALLY, my questions -  is there any way to reduce this overhead of 
passing data into a slave interpreter without the hack of having it 
"call back" for data? Is this issue worth addressing in the core or is 
it expected behaviour for whatever reason? I traced through SlaveEval 
but do not grok exactly why the shimmering (intentionally done) is 
necessary.

/Ashok


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core