On Wed, Feb 22, 2006 at 11:11:45AM +0200, Ulrich Sch?bel wrote: > I tried your script and got, after a slight modification, quite > consistent results. When I tried it as is, I got slightly varying > time results with a peak in the 50 to 100 region. Then I > commented out all lines concerning the deletion, creation > and filling to get the pure retrieval times. Drom then on > I got the following almost invariable results, > > t(1)=538 microseconds per iteration > t(5)=69.2 microseconds per iteration > t(10)=39.9 microseconds per iteration > t(50)=391.48 microseconds per iteration > t(100)=215.61 microseconds per iteration > t(500)=73.154 microseconds per iteration > t(1000)=54.753 microseconds per iteration > t(5000)=40.9094 microseconds per iteration > t(10000)=39.4558 microseconds per iteration > > The t(1) time is probably due to Tcls bytecode engine, but > the t(50) and t(100) times are inexplicable, at least for me. > > The 'mini database' you use is, apart from a few additional > fields, almost identical to the one I used in my previous tests. > > 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 > 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". > Tcl collects its garbage when there is some. Tcls objects are reference > counted and as soon as this count reaches zero the object is cleaned > up. This costs time, of course, but it happens each time the garbage > is due. That has the effect, that garbage collection times are simply > included in execution times, regularly. 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. In any case, this is the SQlite list rather than the tcl-core list, so returning to the subject at hand... > It should not produce the peak times I see at t(50) and t(100). 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-) - Adrian
