From: Gustaf N. <ne...@wu...> - 2006-09-25 09:40:28
|
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 |