[TCLCORE] Re: Hintermayer's string allocation patch

[Eric M. <er...@aj...>]

On Thu, 31 Aug 2000, Donald G Porter wrote:

> > 2.  Tcl is faster in all append cases.  
> 
> All the cases you tested.
> 
> 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}

The results of which I included in one of my posts here?  I have yet
committed this particular change to CVS, but you can see the results of
running this benchmark in my other post.

I believe that what Dan means by "Tcl is faster in all append cases" is
that Tcl, using ckrealloc and the new algorithm for large strings, is
faster than Tcl, using alloc/memcpy/free and the old algorithm.  That is,
the speed benefits from using ckrealloc outweigh the losses from using the
new growth algorithm for large strings, so you still have a net win.  I
think everybody here understands that the new algorithm is slower than the
old algorithm in a head-to-head comparison.  I don't really think that is
relevant.  Right now, Tcl cannot effectively use all of the available
memory.  In my opinion, this is, bluntly, stupid.  There's no reason why
we shouldn't be able to use all available memory.  Particularly when we
claim that you can (at least in newsgroup posts and in our own Tcl
training materials).

Sure, it may be that there are very few people who need to use very large
strings.  If this is your argument, then you have just made my point too:
this patch will not affect most people (if they are not using large
strings, they are using small strings, and will thus still be using the
old algorithm), but those people that are affected will be significantly,
positively impacted.  It may be that there are other ways for the user to
write their code so that they don't have to have a single big string, but
does anybody here honestly believe that at the Tcl level, the programmer
should be worrying about memory allocation schemes?

   Eric Melski                            The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions


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