[TCLCORE] Re: Hintermayer's string allocation patch

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

On Thu, 31 Aug 2000, Jim Ingham wrote:

> So you should make sure the cutoff where you switch from one algorithm
> to the other is well above the size most people will use, then it should
> be ok.  I would argue for erring on the side of high rather than low,
> however, since if you can't get the very last 4-8 Meg of a 128 meg
> string allocation, for example, that is not so bad.  It will almost
> never be an issue, and the solution is to just add some more swap space
> (this is not hard to do on most modern systems) and try again...

On the UNIX systems that I am familiar with, I would definately not use
"not hard to do" to characterize what must be done to "just add some more
swap space."  At the very least, I need to repartition my hard drive.  I
may have to even put in a new hard drive, as I will likely have already
completely allocated every piece of my disk.

In any case, our answer to the question "How big a string can Tcl manage?"
should not be "1/2 of available memory, if you need more get more swap
space."  This seems absurd to me.  Also, I agree that not getting the last
4 MB of a 128 MB allocation may not be so bad in the general case, but in 
the specific case of Tcl, when this happens, the interp panic's, which is
bad.  And it surely makes Tcl look bad if it can't get the last 4 MB of a
128 MB allocation _when the system still has 128 MB of available memory_.

Gerhard's suggestion of using 1/2 available memory as the value to
TCL_GROWTH_LARGE_STRING has some merit, but in practice it will be too
difficult to determine this.  We should be able to just pick a value that
is reasonably larger than the biggest "common" string that Tcl programmers
will need.

   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.