[M3devel] Text structure bites again...

[Dragiša Durić]

On Sun, 2008-03-30 at 13:05 -0600, Rodney M. Bates wrote:
> Just some thoughts:
> 
> Are all the intermediate TEXT values during all the concatenations
> unused (other than for the next concatenation) until the whole
> string is built, and only then get_chars?  If so, a possible
> workaround might be to use a TextWr.T to build the string, then
> TextWr.ToText.  It will keep a more efficient internal representation,
> (expandable array of pointers to mutable buffers of almost 1000 chars
> each,) and ToText is iterative.

  Exellent idea. And working :).

> Even if some of the intermediate strings are needed, but not too
> often, it might be possible to do a TextWr.ToText and Wr.Put
> to put the result right back into the TextWr.T and get  started
> building the next longer string.
> 
> If you like it better to fix the TEXT implementation rather than
> change your application,  I can imagine a better version of TextCat's
> override of get_chars that recurses on only one of the two
> component strings and iterates on the other.  I think it could
> iterate on either component, as long as that is done temporally
> last.

  This implementation makes & and Text.Length() blindingly fast, and &
copy free. Any traversal of "TEXT tree" is potential efficiency problem.

  What I was thinking is to implement AVL tree instead of current one,
thus making traversals as efficient as tree can be, while not burdening
&.

> 
> It could recurse on the component that is not another TextCat.T,
> if there is one, otherwise, recurse on the component that is shorter.
> This would only be a guess at which one is shallower, but might have
> a reasonable probability of being the right guess.
> 
> Dragiša Durić wrote:
> > Imagine string made by 50,000 & operations.
> > 
> > After that, we have very unbalanced tree of TextCat.T's.
> > 
> > Imagine get_chars() invocation by unsuspecting code.
> > 
> > 10MB of default stack goes crash.
> 
-- 
Dragiša Durić <dragisha at m3w.org>