On 23.08.2006, at 17:11, Vlad Seryakov wrote:
In the case when ns_set has only few items, sequential search can be
much faster than hash overhead, so i am not sure about this one
Most interesting:
lexxsrv:nscp 3> ns_set create
d0
lexxsrv:nscp 7> for {set i 0} {$i < 100} {incr i} {ns_set put d0 test
$i test$i}
lexxsrv:nscp 10> time {ns_set find d0 test50} 1000
3.269 microseconds per iteration
lexxsrv:nscp 16> time {ns_set find d0 test99} 1000
4.462 microseconds per iteration
lexxsrv:nscp 18> time {ns_set find d0 test1} 1000
2.093 microseconds per iteration
lexxsrv:nscp 11> for {set i 0} {$i < 100} {incr i} {set xx(test$i)
test$i}
lexxsrv:nscp 21> time {set xx(test1)} 1000
1.527 microseconds per iteration
lexxsrv:nscp 25> time {set xx(test50)} 1000
1.628 microseconds per iteration
lexxsrv:nscp 23> time {set xx(test99)} 1000
1.628 microseconds per iteration
As you see, the ns_set is *way* inferior to
hash tables. Allright, the point is perhaps
that the "set" command is part of the Tcl byte
code so it is inherently faster that ns_set.
But, even then, a moderate set of 100 elements
needs about 3 microseconds to find the middle key
whereas the hash-table needs about 2 msec flat
to locate ANY key.
This all means that even for moderate-sized
sets it pays of to speed them up for searching.
(we'd have to accept some speed penalty for
adding/updating/deleting sets allright, but
nothing is for free).
All measurements are done on my Mac PB 1.5GHZ powerpc.
Cheers,
Zoran
