[PD-dev] Tcl_Eval() vs. Tcl_EvalObjEx()

Hans-Christoph Steiner hans at eds.org
Fri Mar 7 01:35:58 CET 2008


On Mar 6, 2008, at 9:13 AM, Mathieu Bouchard wrote:

> On Thu, 6 Mar 2008, Mathieu Bouchard wrote:
>> On Thu, 6 Mar 2008, Hans-Christoph Steiner wrote:
>>> I am thinking of switching it to use Tcl_EvalObjEx(), which compiles
>>> the Tcl to bytecode, then caches the bytecode.  It also skips some
>>> deprecated actions which Tcl_Eval() still does.
>>> Anyone know anything about this?  I am curious about what the
>>> pitfalls might be before going down this road.
>> Just try it, and see whether it works, and whether it's any  
>> faster. Should be easy to try, no?
>> To make a Tcl string object, just use Tcl_NewStringObj(s,strlen(s)).
>
> Now that I think of it, that code would get recompiled every time  
> it runs, which would make it slower as long as it doesn't contain  
> loops, and as long as the server sends slightly different commands  
> each time. If you want to run things faster, make procs for common  
> code and pass anything variable as arguments to those procs. this  
> is the only way to save time on this. But I'm really not sure that  
> the speed gain is significant...
>
> I know that Tcl keeps a cache of compiled non-procs for the [eval]  
> and/or [expr] command, but I don't recall the specifics, and  
> obviously it doesn't apply if you have a bunch of %d %s changing  
> all of the time in your strings.

With Tcl_EvalObjEx(), the bytecode is cached as part of the object.   
I think in order for that to work with Pd, we'd have to use Tcl_Objs  
in sys_vgui.  This would also have the advantage of making the  
network traffic to something like 10% of what it is now, if Pd and  
Tcl communicated using Tcl_Obj references.

.hc


------------------------------------------------------------------------ 
----

If you are not part of the solution, you are part of the problem.






More information about the Pd-dev mailing list