I found the root of the disappearing lines on Windows, it is indeed related to namespaces. And in that process, I found out that Pd uses Tcl_Eval() to execute the Tcl commands. It turns out that Tcl_Eval() seems to be the slowest Tcl function available for doing this.
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.
.hc
------------------------------------------------------------------------ ----
¡El pueblo unido jamás será vencido!
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)).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
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.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
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.
On Thu, 6 Mar 2008, Hans-Christoph Steiner wrote:
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.
1. why reduce the network traffic? does the network traffic itself slow down things that much, or is it really something else?
2. how do you pass a Tcl_Obj across the network? you could also hold a cache of the last commands in a Tcl dictionary, so that the Tcl_Objs are preserved client-side.
3. how often are lines exactly duplicated? if you don't have much duplication, you can't save much by removing the duplication.
I think that the answer is to simply use proc, and not worry about bytecode, as proc takes care of it better than what you can do otherwise.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada