Re: [naviserver-devel] read/write ns_config

[Zoran V. <zv...@ar...>]

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