[TCLCORE] Re: Hintermayer's string allocation patch

[George H. <ga...@si...>]

In message <200...@po...>, Brent Welch writes:
 : So, it is broken.  It is not that we cannot allocate a 1 or 2 Gig string,
 : it is that we may not even be able to grow a Tcl string that will
 : fit into physical memory/swap space.

We can agree that replacing free/malloc with realloc is Ok.  It may
also be worth looking into tuning the grow rate of strings.  If may be
that realloc sufficiently diminishes the cost of allocations such that
a less aggressive growth rate is attractive.

But I don't agree that it's at all necessary that Tcl be able to grow
a string that exceeds physical memory.  Please make the case for any
application that requires such capabilities.

I especially don't like the "large size" memory parameter that doesn't
scale with memory sizes.  It's an simple matter to write a version of
TclpAlloc (and thereby Tcl_Realloc) that doesn't panic when it runs
out of memory.

 : Also, if you look at the patch, it replaces like 8 lines with 16 lines,
 : and by tuning the "large size" limit and the growth chunk size, we
 : can make the performance hit for things over the "large size" acceptable.
 : 
 : Can we be done with this now?

Please forgive me if I'm a little slow in seeing how the TCT operates.
BTW. Was this how the panic-ing version of TclpAlloc was included?

--gah

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