[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