Hi,
Maybe someon is interested in some findings about the problem
with
Tcl_SetIntObj(Tcl_GetObjResult(interp), 1);
i just workd through the xotcl c code, and found indeed a potential
source for the problem (in the non-frequently used
XOTclOIsMixinMethod() call) and fixed it.
It is my understanding that the problem with the shared result object
happens
only when some c-code sets the result with an shared object somewhere after
the start of the command (e.g. doing an eval). Simple commands
are still safe. When doing some tests, it shows that the version with
Tcl_NewIntObj() is measurable slower than the version with the
reused result object (no wonder) but as well slower than the
version with Tcl_ResetResult().
For the following test, i measured the total time of calling
a simple xotcl command (... info superclass <someclass>), including
all xotcl overhead. The xotcl command was called 100.000 times, the test
was performed 100 times to get useful granularity from the timer.
puts [time {time $cmd 100000} 100]
Tcl_SetIntObj(Tcl_GetObjResult(in), 1); 168524,55 100,00%
Tcl_SetObjResult(in, Tcl_NewIntObj(1)) 186699,12 110,78%
Reset & Tcl_SetIntObj(Tcl_GetObjResult(in), 1); 178237,24 105,76%
The timings are from a PowerPC G5 with 2.1 GHz.
This shows that the runtime of the xotcl command is 10% slower with
NewIntObj() and 5% slower with ResetResult() than the runtime
of the command with setting the result obj. I get similar
timings for other commands like "... isobject ..." as well.
The differences are bigger than expected. Certainly, for some
applications that might not matter....
-gustaf neumann
