[TCLCORE] Re: Hintermayer's string allocation patch

[Donald G P. <dg...@ca...>]

> > > 2.  Tcl is faster in all append cases.  

> > Add this to string.bench and check the results:
> > 
> > bench -desc "STR append (1MB + 1KB * 1000)" \
> > 	-body {str-append $base $kilobyte 1000}

> Does this case produce significantly different results from:
> 
> bench -desc "STR append (1MB + 3KB * 1000)" \
>         -body {str-append $base $kilo3 1000}

Yes, because (3KB * 1000) compares 2 big reallocs (original algorithm)
with ~400 small reallocs (new algorithm).  (1KB * 1000) compares only
1 big realloc (original algorithm) to ~300 small reallocs.  

Results from Tcl 8.4a1:

$ tclsh src/tclbench/libbench.tcl src/tclbench/tcl/string.bench
047 {{STR append (1MB + 1KB * 1000)} 61321}

Results from Tcl in CVS, 2000 August 31:
$ src/tcl8.4/unix/tclsh src/tclbench/libbench.tcl src/tclbench/tcl/string.bench ...
047 {{STR append (1MB + 1KB * 1000)} 68370}

Now, neither test is "the right test".  They're both particular tests,
but this should dispute the claim that the new patch is faster
"in all cases".

It's worth considering the asymptotics, too.  As others have
observed, the O(N**2) behavior of the new algorithm will bite when
the "1000" in these benchmarks grows to 10000, 100000, 1000000, ...

Another concern is the platform-specific tuning necessary to choose
good values for TCL_GROWTH_LARGE_STRING and TCL_GROWTH_MIN_ALLOC.
How will good values for these be determined over all the platforms
Tcl runs on and will run on over the next, say, 5 years?

DGP

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.