[Python-3000] Making more effective use of slice objects in Py3k (original) (raw)

Josiah Carlson jcarlson at uci.edu
Thu Aug 31 07:23:05 CEST 2006

Ron Adam <rrr at ronadam.com> wrote:

Josiah Carlson wrote: > If views are always returned, then we can perform some optimizations > (adjacent view concatenation, etc.), which may reduce running time, > memory use, etc. d Given a empty string and a view to it, how much memory do you think a view object will take in comparison to the string object?

On 32 bit platforms, the current implementation uses 8 more bytes than a Python 2.4 buffer, or 44 bytes rather than 36. The base string object takes up at least 24 bytes (for strings of length 2-4, all length 1 and 0 strings are interned).

Wouldn't there be a minimum size of a string where it would be better to just copy the string?

What do you mean by "better"? If your question is: at what size would returning a Python 2.x string be more space efficient than a the current view implementation, that would be a string of up to 24 bytes long.

However, as I said before, with views we can do adjacent view concatenation...

x,y,z = view.partition(a)
left_with_sep = x+y
right_with_sep = y+z

If we returned views from view addition, then both of the additions above would be constant time operations. But if we returned strings from view additions, the above two additions would run in O(n) time together.

If we were really crazy, we could even handle non-adjacent view concatenation by checking the readonly flag, and examining data to the right of the current view. But even I'm not that crazy.

More information about the Python-3000 mailing list