Dan Sugalski wrote: > >If the internal string API is a tree instead of a contiguous memory block, > >the tagging could be done at the node or branch level. > > > >Besides, you get nondestructive inserts. > > Yup. The only problem is that it makes the string data significantly more > complex. I don't think it's a win for raw data. Perhaps for fancier data > it'd work. the simplest tree is one node with a raw block in it. Only when you start doing things to it substr($A, 27, 3, $B) and suchlike does deferring the copying give a win. Say $A is 35 megabytes long and $B is 23K. Currently, and in any string representation that uses raw blocks, we have to do these things: copy substr($A,27,3) to return value if needed Allocate a new 36M block copy substr($A,0,27) copy $B copy substr($A,30) set $A's data pointer to the new block free $A's old block With a tree representation, the assign-to-middle operation becomes: Return Value if needed is substr($A,27,3) Create a new string-segment-list-node Segment 1: substr($A,0,27) Segment 2: $B (which might be another tree) Segment 3: substr($A,30) return $A's old top node to the node pool set $A's data pointer to the new top node set $B to copy-on-write mode, so future changes to $B do not affect $A no new allocations! This kind of thing also allows us to do "live interpolation" in which ql" this will $change " might rewrite to a magic scalar that evaluates the join every time it is fetched instead of once when it is built. Mixed-type? Yes! You could even have a value that is not a string at all, hanging off your string tree.Thread Previous | Thread Next