Tcl - Can someone explain this performance issue?

Author

Can someone explain this performance issue?

Twylite

2007-11-28, 7:16 pm

Hi,

I have a proc to splice together n lists, creating a list that
contains [lindex $list1 0] [lindex $list2 0] ... [lindex $list-n 0]
[lindex $list1 1] ... etc.

I have a fairly decent microbenchmark that constructs around 1000
lists of 10-20 elements each (each element is a different md5 hash in
hex format), and then splices together pairs from this set of lists.
In total I time {} about 25000 splice operations to get the benchmark.

If I run the code below as-is, the second benchmark run gives around
48000 micros per iteration (for pairs of lists).

If I run the code with the "set iterscript" uncommented, I get around
36500 micros per iteration.

proc ::listx::splice2 {args} {

set varcounter 0
set iterscript "lappend list_S"
set eachspec [list]

foreach arg $args {
set v "v[incr varcounter]"
append iterscript " \$$v"
lappend eachspec $v $arg
}

# set iterscript "lappend list_S \$v1 \$v2"

set list_S [list]

foreach {*}$eachspec $iterscript

return $list_S
}

Needless to say I have checked that the iterscript I build and the one
I define are identical - in fact I can add an if { $iterscript_built
ne $iterscript } { error DIE } to that code and it will run happily.

Does anyone have any wisdom on this apparently bizarre situation?

In case it matters my tcl_patchLevel is 8.5a6. Yes, I'm planning to
upgrade ;p

Regards,
Twylite

Alexandre Ferrieux

2007-11-28, 7:16 pm

On Nov 28, 4:12 pm, Twylite <twylite.cr...@gmail.com> wrote:
> Does anyone have any wisdom on this apparently bizarre situation?
>

I believe so. If you set $iterscript to varying values, its bytecodes
don't get a chance to be reused as much as when it is constant.

Moreover, in this kind of situations, to crank the most out of
bytecode compilation, a good idea is to dynamically call [proc] (with
computed procbodies), because much more is compiled than with a
variable argument to a control struct.

-Alex

schlenk@uni-oldenburg.de

2007-11-28, 7:16 pm

Twylite wrote:
> Hi,
>
> I have a proc to splice together n lists, creating a list that
> contains [lindex $list1 0] [lindex $list2 0] ... [lindex $list-n 0]
> [lindex $list1 1] ... etc.
>
> I have a fairly decent microbenchmark that constructs around 1000
> lists of 10-20 elements each (each element is a different md5 hash in
> hex format), and then splices together pairs from this set of lists.
> In total I time {} about 25000 splice operations to get the benchmark.
>
> If I run the code below as-is, the second benchmark run gives around
> 48000 micros per iteration (for pairs of lists).
>
> If I run the code with the "set iterscript" uncommented, I get around
> 36500 micros per iteration.
>
> proc ::listx::splice2 {args} {
>
> set varcounter 0
> set iterscript "lappend list_S"
> set eachspec [list]
>
> foreach arg $args {
> set v "v[incr varcounter]"
> append iterscript " \$$v"
> lappend eachspec $v $arg
> }
>
> # set iterscript "lappend list_S \$v1 \$v2"
>
> set list_S [list]
>
> foreach {*}$eachspec $iterscript
>
>
> return $list_S
> }
>
> Needless to say I have checked that the iterscript I build and the one
> I define are identical - in fact I can add an if { $iterscript_built
> ne $iterscript } { error DIE } to that code and it will run happily.
>
> Does anyone have any wisdom on this apparently bizarre situation?

My guess at the situation:

If you set iterscript in the proc, the bytecompiler can bytecompile it
while compiling
the proc, as it is a literal expression while it
does not if you construct it at runtime. Try the new diassamble
command
from the betas to see if I'm right,

Michael

Sponsored Links