Re: [Python-Dev] String views (was: Re: Proof of the pudding: str.partition())
skip@pobox.com wrote:
How would this work? One of the advantages of the current string is that the underlying data is NUL-terminated, so when passing strings to C routines no copying is required.
I didn't say it would be easy. Just that it's about the first cases where I've seen there could be a real advantage to using string views. And I don't even know that. One of the big disadvantages of string views is that they need to keep the original object around, no matter how big it is. But in the case of partition, much of the time the original string survives for at least a similar period to the partitions. Tim Delaney
Tim> One of the big disadvantages of string views is that they need to Tim> keep the original object around, no matter how big it is. But in Tim> the case of partition, much of the time the original string Tim> survives for at least a similar period to the partitions. Not necessarily. Presumably a string view would reference another string object's data buffer. A possible optimization would be to convert from a view to a normal string once the original strings' refcount dropped to one, particularly if the view's size was substantially smaller than that of the original string. Skip
On Aug 31, 2005, at 10:21 PM, skip@pobox.com wrote:
Tim> One of the big disadvantages of string views is that they need to Tim> keep the original object around, no matter how big it is. But in Tim> the case of partition, much of the time the original string Tim> survives for at least a similar period to the partitions.
Not necessarily. Presumably a string view would reference another string object's data buffer. A possible optimization would be to convert from a view to a normal string once the original strings' refcount dropped to one, particularly if the view's size was substantially smaller than that of the original string.
I suspect this would be a pessimization most of the time, as it would require keeping a list of pointers to all the views referencing the string object. James
James> I suspect this would be a pessimization most of the time, as it James> would require keeping a list of pointers to all the views James> referencing the string object. I'm skeptical about performance as well, but not for that reason. A string object can have a referent field. If not NULL, it refers to another string object which is INCREFed in the usual way. At string deallocation, if the referent is not NULL, the referent is DECREFed. If the referent is NULL, ob_sval is freed. Skip
participants (3)
-
Delaney, Timothy (Tim) -
James Y Knight -
skip＠pobox.com