Version 20 of Elegance vs. performance

if 0 {Richard Suchenwirth 2003-08-08 - You can write an algorithm elegantly (i.e., in few lines of code, using few or no local variables, etc. - see the Zen of Tcl), or performantly (i.e., not wasteful in time or memory). Ideally, these two come together, but in reality, elegant algorithms may show bad performance.

Consider this elegant way of computing the sum of a list of numbers:}

 proc sum1 list {expr [join $list +]}

if 0 {and the more conventional way, which uses 2 local variables:}

 proc sum2 list {
    set sum 0
    foreach i $list {
        set sum [expr {$sum+$i}]
    }
    set sum
 }

#--- The only difference here is that the expr arguments are not braced:

 proc sum3 list {
    set sum 0
    foreach i $list {set sum [expr $sum+$i]}
    set sum
 }

AK: How about this sum4, (if we know that there are only integer numbers to sum) ?

 proc sum4 list {
    set sum 0
    foreach i $list {incr sum $i}
    set sum
 }

if 0 {Here is a little testframe to illustrate the respective performances, and draw them as curves on a canvas. It shows that sum1 (red) takes exponential time as lists grow longer, while sum2 (blue) remains pretty linear. sum3 (green) is initially worse than sum 1, but from the break-even point on it's better:

}

 pack [canvas .c -bg white -width 600 -height 500] -expand 1
 .c create line 0 500 0 500 -fill red  -tag sum1
 .c create line 0 500 0 500 -fill blue -tag sum2

 for {set i 1} {$i<600} {incr i} {
    set list [lrange [string repeat "1 " [expr {$i*2}]] 0 end]
    set t1 [lindex [time {sum1 $list}] 0]
    .c coords sum1 [concat [.c coords sum1] $i [expr {500-$t1/40}]]
    set t2 [lindex [time {sum2 $list}] 0]
    .c coords sum2 [concat [.c coords sum2] $i [expr {500-$t2/40}]]
    update
 }

if 0 {I was a bit surprised by the big difference. I will continue to start with elegant code, and tune it to performant when necessary, but deep in my heart I dream of a language that can performantly evaluate elegant expressions.... }

SS: LISP seems the nearest today, there are compiled versions of CL and Scheme performing nearly half of native code speed. Also the SUN Self implementation was only 4/5 times slower then optimized C.

RS: In Lisp, it would go like this (tested on Emacs Lisp):

    (defun sum0 (list) (eval (cons '+ list)))

Peter Lewerin: or like this (Common Lisp, LispWorks implementation):

    (defun sum0 (list) (apply #'+ list))

RS Emacs Lisp allows to do without the # (which denotes a function name):

    (defun sum0 (list) (apply '+ list))

SS: In Scheme it looks like this:

    (define (sum0 list) (apply + list))

HZe: I tried out this script and was (again) amazed how simple things can be done in TCL. Just for curiosity I changed sum3 to be identical to sum2. I expected to have the red and the green curve at about the same position..., but it was not. Can anyone explain?

DGP: Probably shared literals and bytecode compiling.

HZe: stupid me, I mixed up the colors. I changed sum3 (green), so that it is equal to sum2 (blue). The result is as I expected: blue and green are about the same. Red (elegance) is way off. Sorry...

I also changed the script a bit and added sum4:

 proc sum1 list {expr [join $list +]}

 proc sum2 list { 
    set sum 0
    foreach i $list {
        set sum [expr {$sum+$i}]
    }
    set sum
 }
 proc sum3 list {
    set sum 0
    foreach i $list {
        set sum [expr {$sum+$i}]
    }
    set sum
 }

 proc sum4 list {
    set sum 0
    foreach i $list {incr sum $i}
    set sum
 }

 pack [canvas .c -bg white -width 600 -height 500] -expand 1

 array set color {
    1 red
    2 blue
    3 green
    4 yellow
 }
 foreach idx {1 2 3 4} {
    .c create line 0 500 0 500 -fill $color($idx)  -tag sum$idx
 }

 for {set i 1} {$i<600} {incr i} {
    set list [lrange [string repeat "1 " [expr {$i*2}]] 0 end]
    foreach idx {1 2 3 4} {
        set t [lindex [time {sum$idx $list}] 0]
        .c coords sum$idx [concat [.c coords sum$idx] $i [expr {500-$t/40}]]
    }
    update
 }

Category Performance