On Wednesday 22 February 2006 15:59, Adrian Ho wrote: > > Do you come to similar results? > > Nope, mine were a lot more consistent (Centrino 1.6GHz laptop, 512MB RAM): > > t(1)=254 microseconds per iteration > t(5)=186.6 microseconds per iteration > t(10)=156.1 microseconds per iteration > t(50)=147.24 microseconds per iteration > t(100)=144.88 microseconds per iteration > t(500)=153.658 microseconds per iteration > t(1000)=142.218 microseconds per iteration > t(5000)=142.7774 microseconds per iteration > t(10000)=143.1704 microseconds per iteration
As were Richards. Looks like an issue of my machine/installation, but I'm perfectly clueless. > > I have to oppose your statement, Tcl has garbage collection. > > It doesn't, at least in the sense, that it calls a routine to > > collect unused space and free it at arbitrary times, i.e. during > > idle times. > > Ah, that's where our perspectives differ. The definition of "garbage > collection" which I'm operating from (which I believe is the classical > CS one) makes no reference whatsoever to time, other than the implicit > "at some point after it's been identified as garbage". OK, almost no difference except for the definition. > While that's true, I'd point out that unset'ing a large list/array, > or otherwise destroying a heavily-referenced Tcl_Obj, can cause a huge > cascade of derefs/deletes, so it's not necessarily the case that Tcl's > GC times are always predictably similar even across iterations of the > same script. Right, but my test script is way too simple for such effects. > I'm keeping an open mind on this one, since I have no hard data to back > up any conclusion whatsoever. And since you've subsequently indicated > that it's now a non-issue (esp. in comparison to MySQL), I guess I'll > shut up now. 8-) Thanks for your support. If you have an idea on this later on, please let me know. I'm staying tuned. Kind regards Ulrich
