[TCLCORE] Re: Hintermayer's string allocation patch

[Jeffrey H. <jef...@aj...>]

> -----Original Message-----
> From: ak...@bl... [mailto:ak...@bl...]On
	...
> ... allocate until you the wall and
> then retract from the boundary to fill the rest in smaller
> increments.
>
> What I like about this algorithm is that it not only preserves maximum
> performance for as long as possible while still being able to fill the
> memory to the max. but also that it is "self-tuning".
>
> With this I mean that there is no need to adjust (tinker / fiddle
> with) some parameters like with the current patch proposed as by
> Gerhard to adapt the core to the host it is running on to get good
> performance on average. We get this automatically.

While this is a good approach, it does require a more extensive patch
to the core - adding new alloc stubs routines (which is probably a
good idea anyway).

Also, it still leaves behind the remnants of poor mem allocation in
Tcl if you use multiple large objects.  For the worst case, each string
in Tcl takes up twice as much space as it needs to.  Thus if we are
working with multiple large objects, we can have 120MB of actual data
taking up 240MB of memory, and we still hit a wall because a new large
object may not get any more memory, although 120MB is wasted.

Of course, the same can happen for lots of smaller objects if you have
the min algorithm switchover high, so there's no 100% win.  Thus the
point is, do we want to accept the fact that Tcl can't effectively use
more than half the available memory?  I find that hard to swallow, which
is why a trade-off should be considered, one that kicks in at a hard-coded
level (where excessive 2* waste is a lot more painful).

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (née Scriptics)

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