[Python-3000] Making more effective use of slice objects in Py3k
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
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
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