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.